software solutions / project leadership / agile coaching and training

Moving past the monolith

Posted on November 4, 2017

As long as people have been writing software, well-intentioned developers have cobbled together elegant solutions that have turned into digital versions of Frankenstein’s monster. While these systems don’t threaten your life, they limit your ability to adapt to change, keep up with competition, and maintain your overall sanity.

Numerous posts like this have been written about the Monolith, yet we’ve all created them. I’ve created several of them, and sadly in the not so distant past. I’ve moved on from my last one, but my former co-workers like to inform me every time they’ve managed to rewrite a portion of it.

Why does this keep happening? No one likes maintaining the big, old legacy system that is difficult to change, that is written using old frameworks, or just follows practices that the mythical “everyone” used 5 years ago. When I started out creating the monoliths I’ve created, I certainly didn’t mean to create a problem.

I think it’s always good practice to look back on past projects and think about what I could’ve done differently. I know hindsight is 20/20, but I feel like there are always places where I could’ve made a conscious decision to create a new system rather than just add onto an existing one. I feel like in almost every case, I missed the chance because I wasn’t planning for change.

Let’s be honest, the rate of change is growing exponentially. We aren’t living in a world where you create a mainframe that’s going to run for 30+ years. I have code in my system that we consider “legacy code” that is less than a year old. Whatever hot new JavaScript framework you’re choosing today will be obsolete in a couple years.

As weird as it sounds, we need to starting creating systems so that we can easily replace them.

  • Over the lifetime of your system, you may want to change JavaScript frameworks/languages/platforms… multiple times
  • You will put yourself behind in the recruiting game if you are using old technology
  • You need to be able to change frameworks without having to rewrite the entire application
  • You need to consider how the code you’re writing today will need to be rewritten

This means that we need to start building more modular software so that we can easily replace things or just start building things in newer technology.

Some of you might immediately start thinking microservices, but it doesn’t have to be. Microservices are one solution (with their own set of problems), but there are things you beyond microservices to make your code more modular and maintainable.

I would argue that one of biggest issues isn’t a lack of automated tests, it isn’t bad process, it’s that we continue to create large, complex systems that become too hard to change. Over the next several posts, I’ll cover many topics related to writing modular software:


  1. [...] This is part of a series of posts about Moving Past The Monolith. To start at the beginning, click here. [...]

    Moving past the monolith, Part 1 – Organizing your code into modules « Jon Kruger's Blog — November 4, 2017 @ 11:27 pm

  2. [...] This is part of a series of posts about Moving Past The Monolith. To start at the beginning, click here. [...]

    Moving past the monolith, Part 4 – Using the Service Object pattern « Jon Kruger's Blog — November 4, 2017 @ 11:27 pm

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
Ditching the Office - How an everyday corporate development team turned into a remote working team
From Stir Trek 2018
From Stir Trek 2017, cbus.js 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010