Jay Fields is a software developer at DRW Trading. He has a passion for discovering and maturing innovative solutions. His most recent work has been in the Domain Specific Language space where he's delivered applications that empowered subject matter experts to write the business rules of the applications. He is also very interested in maturing software design through software testing. Jay is a DZone MVB and is not an employee of DZone and has posted 112 posts at DZone. You can read more from them at their website. View Full User Profile

When to Break Apart Your Application

03.08.2012
| 4580 views |
  • submit to reddit

At speakerconf Aruba 2012, Stefan Tilkov presented on the topic of building Systems. One aspect of his presentation that really struck a chord with me was around the competing desires while designing and delivering an application. This blog entry is about summarizing that aspect and what I took away from it.**

Stefan noted that early in an application's life, a monolithic application is far easier to deliver; however, as the application grows, what is important begins to change. The slide to the right shows how priorities can change over time.

While starting with a monolithic application is easier to deliver, that application often grows to an unmaintainable size - i.e. the vast majority of the time we boil the frog. Stefan argued that the benefits are so obviously there that for an application of any moderate size it's more efficient to bite the bullet and break things up (where logical) in the beginning.

I'm guessing the vast majority of the applications that Stefan and innoQ encounter probably began knowing that they would grow to significant size and would have benefited from any type of modularization, but my working environment is a bit different. When I start something new for a trader at DRW -

  • the project may never grow to the unmaintainable size
  • if it does, it's likely that I'll want things broken up in a way that I couldn't have anticipated when the project began.
Given my context, I couldn't conclude that things should be broken up immediately, but I didn't want to ignore the point that Stefan was making about goals changing over time.

Stefan also had a slide about Modularization (also on the right) that gave numbers and recommendations on how to break things up. This slide reminded me of Matt Deiters' presentation at speakerconf Rome 2011. Matt told us about his experience teaching kids in Africa to program. While teaching programming, Matt observed that giving the children the single rule that they shouldn't have methods longer than 10 lines resulted in the children writing code with SRP, encapsulation, and other positive attributes. Matt argued that beginning with a simple rule that could get you 80% of what you want is likely better than 10 rules that, if followed correctly, could get you 100% of what you want.

I applied Matt's idea to Stefan's talk and suggested that perhaps the easiest thing was to take Stefan's modularization table and strictly adhere to changing things when LOC thresholds are broken. This would allow you to quickly deliver a monolithic application early in the development process, while avoiding boiling the frog in the future - once you cross the agreed upon magic number (LoC) then you aggressively address breaking the application into smaller and independent modules/processes/components/projects/whatever.

This strategy gives a nod to the fact that priorities do change as an application evolves and it's best to evolve the application along with those priorities, but not when it's too late. I plan to try this on my next greenfield application.

** I'm going from memory, so I could be slightly off. Don't hold Stefan accountable for my interpretation of his ideas.

Published at DZone with permission of Jay Fields, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Oleg Kozlov replied on Fri, 2012/03/09 - 5:19pm

I had a pretty good experience at my last startup with an application starting small and monolithic and growing into an unmaintainable  monster after 3-4 years (it’s now about 7 years old, although I’m no longer with that company). Later, when we started building a new generation product for the same company, keeping in mind what we learned from the first application we designed an SOA application broken up into relatively independent services from scratch. While there was certain amount of overhead – the fact that developers could focus on their own components without stepping on each other feet and a resulting much tighter release cycle for each individual component – we actually ended up releasing the application sooner than if it was build as a monolith. I have to admit that in that case we knew that the app will either have to scale to handle lots of traffic pretty fast or die if the business idea doesn’t prove successful.

In case when starting a new application and not knowing whether it will grow big enough to require a split – I would start with a single application but modularize it internally and make sure that various components/packages are loosely coupled and relatively independent. This requires some careful design and keeping the idea of potentially having to split the app constantly in your mind. Use well-defined interfaces for each module. That way when/if the day comes - it will be much easier to do the split the application along the module borders.

Dapeng Liu replied on Sun, 2012/03/11 - 10:10pm

"the only way to do it fast is to do it right" 

Christophe Blin replied on Mon, 2012/03/12 - 3:41am

Given your table, a monolith is 50 LOC : then I agree, delivering a monolith is impossible because nothing very interesting can be achieved in 50 LOC.

Nowadays, there is really no excuse to deliver a monolith of 1000 LOC in the first place (even for very simple applications).

First, decoupling GUI and business logic is a must that you are required to achieve with TDD (and TDD is the faster way to developp business logic nowadays).

Then, for the GUI, it is impossible (except if you want to commit suicide) to start without a framework: following the same rules as the framework is often simple and leads to maintainable  code (given the framework you chose is correct).
For ex, if you start a webapp in JS using extjs, start with components and do not hack a screen in 1 js file !

And for the backend, this is the same.
For ex, if you do a webapp in java, use JEE6 and follow the rules.

Conclusion : except if you have an app without business logic or you have less than 1000 LOC, delivering a monolith in the first place shows (IMHO) that you are not a good developper

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.