Agile Zone is brought to you in partnership with:

Ayende Rahien is working for Hibernating Rhinos LTD, a Israeli based company producing developer productivity tools for OLTP applications such as NHibernate Profiler (, Linq to SQL Profiler(, Entity Framework Profiler ( and more. Ayende is a DZone MVB and is not an employee of DZone and has posted 485 posts at DZone. You can read more from them at their website. View Full User Profile

Maintainability, Code Size & Code Complexity

  • submit to reddit

The most maintainable codebase that I worked with grew at a rate of about ~10 KLoC per month, every month. There wasn’t a large team there, it ranged fro 3 – 6 people. This is the project that I think about whenever I had to talk about good code bases.

It is a WebForms project (under protest, but it is).

What make it maintainable? Not the WebForms part, which wouldn’t come as a surprise. What make it maintainable is that it is the first project where I had applied the notion that large swaths of simple code is better than smaller code base with higher complexity. You could see example of this sort of architecture in the Alexandria and Effectus applications.

Note: I am doing things like measure KLOC here mostly because it is a number that I can measure. As I am saying in this post, KLOC has very little to do with maintainability.

The problem can be expressed well using the graphs. This is a representation of the complexity of the application as it grows, lower maintainability cost is better.


The problem with the smaller and more complex code base is that the complexity tends to explode very quickly. With the larger code base, you end up more or less on the same plane.

But the above chart is somewhat misleading, because it make the hidden assumption that in both code styles, you’ll have the same amount of code, which is obviously false. Here is what is probably a more accurate representation of how much code is written for style per # of features.






This doesn’t look right. Not when we compare it to the chart above. Of the top of my head, I would expect the second chart to be the mirror image of the first one. But it isn’t. And the reason that it isn’t is that each feature you write still cost you some amount of code. And the rate of growth per features added is pretty constant either way.

Putting the two charts together, you can see that it means that even code styles with focus on less code in favor of more complex solutions grow, and that as they grow, they become less maintainable.

So far I have been very vague when I was talking about “complex” and “simple”. In part, this is because those are somewhat hard to define. There would be people who would claim that ORM leads to complex codebases, but I would obviously disagree.

For my part, I also strongly advocate of having a strong core of infrastructure that gives services for the rest of the application, and that tend to be complex piece of coding. But that is also something that is fixed, once the infrastructure is written, it tend to be static, so that saves you from the fate outlined above.

When I look at a piece of code, I do the usual evals (nesting, conditionals, cyclomatic complexity, etc), but I also look at how often the developers reached for a hammer and beat everything around to submission. There is a lot of gut feeling here. But I do have one objective metric to use to tell you whatever a piece of code fit either style.

In the fight between Don’t Repeat Yourself an Single Responsibility Principle, SRP wins, every single time.

Any time that I have seem code that did double (or triple or dozenile) duty, it led to the sort of “we have to write less code” style of coding that ended up in a quagmire.

Published at DZone with permission of Ayende Rahien, 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.)


Manfred Schäfer replied on Fri, 2010/11/26 - 2:58am

You're absolutely right. The principle of building up complex systems out of small, nearly trivial parts is underrated. I always try to put as many code of my applications into static methods with no or minimal dependencies. And into small and immutable classes. Scala will help further with functional programming and the traits feature.

Cosmin Mutu replied on Mon, 2010/11/29 - 3:02am

"In the fight between Don’t Repeat Yourself and Single Responsibility Principle, SRP wins, every single time."

 SRP and DRY are not exclusive principles (one does not exclude the other). Either of the two principles can be used inadequately.

from WIKI:

DRY:  The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." When the DRY principle is applied successfully, a modification of any single element of a system does not change other logically-unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

SRP: Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

I personally see DRY as multiple SRPs put together. :)


Hassan Turhal replied on Sun, 2012/09/16 - 2:47am

Higher complexity adds a lot of cost to a project for relatively minimal gain. Still there is a lot of drive out there to add complexity, and I believe the key driver there is challenge.

Writing simple code is not gratifying until down the road when you realize that bringing those extra 4 green developers is a whole lot simpler; Going off and doing something and then coming back to look at it is a whole lot simpler; Adding that new feature is a whole lot simpler; Fixing that bug that got missed is a whole lot simpler.

Are you new to Java?

Comment viewing options

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