software solutions / project leadership / agile coaching and training

Moving past the monolith, Part 8 – Planning ahead

Posted on November 4, 2017

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

Most of us are well-intentioned and never set out to create the giant monolith that weighs down the entire company, but it continues to happen everywhere. After making the mistake many times myself, I’ve realized that they only way to stop this from happening to be more proactive.

We need to discuss modularity when we start creating applications. We need to discuss it any time we move into a new set of functionality. We need to discuss it throughout the life of the application before we get past a point of no return. We need to be thinking now about how someone is going to need to replace the code that we’re writing today.

We can’t just write up a bunch of tickets and have a bunch of developers write code over many years and expect that we’ll end up with something modular. This will always lead to a monolithic application. The only way to avoid this is to make modularity an important design consideration.

This might mean changing how we design our domain models, creating copies of data that are sourced from a master copy, creating service boundaries between modules (either physical or logical), and possibly doing a little more work to protect your ability to change.

This is something your whole team needs to be aware of. Your leads might not know about that code that blurs the module boundaries until it’s too late and you don’t have time to refactor the code. Everyone needs to understand why you’re building modular code and how you plan on doing it.

My experience with modularity

After building many monoliths, I’ve been using these concepts on my current project, and we are reaping the benefits. We have many different deployable modules, and several different solutions (less compiling!). We have modules on very different deployment schedules — some deploy when needed, some deploy on regular schedules, and some don’t deploy at all. Some have modular code but need to be split out into their own deployments so that they can be deployed independently. Some of our code still feels monolithic — some projects are hard to change, take a long time to compile, and some of it is on our list of things to refactor, but since it’s not built in a modular way, do so is proving to be difficult.

I’m really excited about where we are headed, and I’m more confident than ever that we’re going to be able to build large enterprise applications without creating a monster or ending up with a giant .NET solution that takes 3 minutes to rebuild.

I would love to hear from anyone else taking this approach, and I would love to know how it’s going for you and what lessons you’ve learned. I imagine I will look back on this post a year from now and want to make a lot of edits based on things that I’ve learned. I’m OK with that, that just means that I’m learning, and learning is a good thing.

If you’ve made it this far, thank you for joining me on this journey! I hope that something in here will empower you to start creating more modular and maintainable software.

No Comments »

No comments yet.

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