Skip to content

Software Structure Can Reduce Costs and Time-to-Market

February 19, 2012

First article in a series on on how to use Software Structure to improve business performance.

What are the consequences of the structure of a software code base?  Does software structure make a significant difference to the enterprise that develops software for sale as a software product or Software-as-a-Service?  This article explores these questions.  I think you’ll find the exploration interesting, surprising, and hopefully useful.

Throughout this paper I use Return on Investment (ROI) as the measure to quantify the value of a software code base to a business.  I hope you will come to see that the value of a code base to a business is both something to sell to customers in the short term as a product, and at the same time a key productive asset for the business over the long term.  This perspective can make a vast difference to a business’ success.

Software structure is basically about how the various objects in a software code base collaborate with each other.  Structure is the relationship between objects through their instances, methods, properties and events.  As this article details, all other things being equal, the structure of software largely determines how long it takes and how expensive it is to develop, test, extend, and maintain a software system.  Why?  Because well-structured software takes much, much less elapsed time to extend and maintain than poorly structured software.  Indeed, given a particular feature it can take exponentially less time to implement it in a well- structured code base, than to do so in a poorly structured code base.  It could easily take 2, or 5, or 10 times longer (or even more) to implement that same feature in a poorly structured code base.  And for a business, software development elapsed time is both money and opportunity.

Well-structured software is modularized in a way that cleanly and effectively divides up the internal functionality of a code base into bite sized chunks.  The bite sized chunks are easily understandable and manageable in 3 ways:  1) In the implementation of their internal functionality, 2) (very important) in the effectiveness of the separation of their particular functionality from the rest of the system, and 3) (also very important) in their relationships and connections to other bite sized chunks in the system.

Poorly structured code is called spaghetti code since the interconnections between numerous chunks of code and their methods, properties and events are tightly coupled (hard wired) and tangled, contorted, twisted and intertwined like individual pieces of pasta mixed up with each other and the sauce.  Further, such interconnections between code chunks are chained together, so that changes in one thing cause a ripple effect resulting in changes in many things. Plus, the chunks of code themselves are often not separated out from the rest of the software in a useful way, nor at a useful level of granularity. Over time as more and more features and their code is added to a poorly structured code base, the ineffective separation of functionality into chunks and the tightly coupled tangle of interconnections cause an exponential expansion of complexity in the code base.  This acts to compound the problem each time more code is added to a poorly structured code base.

Spaghetti code takes much, much longer for a developer to learn via discovery by working with the code to gain understanding (since there is often little or no documentation in spaghetti systems), to find the causes of bugs, to fix bugs, to extend when adding new features, and to test.  The economic result of a poorly structured code base is:  A significant portion of the time spent working with spaghetti code is not directly spent on fixing a bug or implementing a new feature, i.e. not directly adding more value to the code base.  Instead, a whole lot of developer time is spent sifting through a tangle of existing code, discovering and understanding its complex and contorted interrelations, moving bits of existing code from here to there, from there to here, rewriting portions of existing code so as to hook up a new feature that has to somehow fit in to the existing tangle, and fixing bugs caused by implementing new features due to the hard-to-test nature of poorly-structured software.

Over the life of a code base, a business with a poorly structured code base ends up paying its developers to spend lots of their time doing things that are not adding business value, but rather compensating for the lack of an effective structure to their code base.  And, this cost is incurred over and over, with each bug fixed, with each feature added, and through each new release cycle.  It typically grows worse and worse over time as the complexity of the spaghetti code base grows exponentially. To contrast, a business having a well-structured code base gets a whole lot more return from its developers since they spend much more of their time directly adding new value.

The rule of thumb I’ve heard about for decades (and verified by many empirical studies in the last 30 years) is that on average roughly 60% of the lifetime costs of a software code base occur in the maintenance and enhancement phase, subsequent to its initial release.  Thus, the Maintenance/Enhancement costs of a code base weigh in heavily in the calculation of the ROI of software systems developed by a business, considering them as part of the “investment” side of that calculation.

Since 60% is an average, individual cases can be significantly more or less than 60%.  A recent issue of MSDN Magazine contains an article stating this range was 40% to 80%, with the average being 60%.   (See the bibliography for citations.) Clearly, a poorly structured code base has higher costs, so one can expect that Maintenance/Enhancement cost after the initial release would be on the high end of this range, near 80% of total lifetime costs.  Likewise, one would expect that a well-structured code base would have a below average Maintenance/Enhancement cost, near 40%.  How do these percentages work with money?  The dollar result is not intuitively obvious from looking at the percentage numbers.

Consider the following cost scenarios, all assuming that $1,000,000 is invested to develop the initial release of a software product or Software-as-a-Service.  Watch what happens to center column, which lists 2 things: 1) The code base’s “Lifetime Maintenance/Enhancement Cost” as a percentage of “Total Lifetime Cost” and 2) the actual dollar amount of that percentage.

The scenarios in the below table have the center column increasing from less-than-average of 40% (a very well-structured code base), to average of 60%, to higher-than-average of 80% (a very poorly structured code base).

Cost of Initial                 Lifetime Maintenance /                    Total Lifetime Cost
Development                  Enhancement Cost                             (TLC)
% TLC Dollar Cost             % TLC Dollar Cost                               % TLC  Dollar Cost
60%     $1,000,000             40%   $  670,000    Well-Structured     100%   $1,670,000

50%     $1,000,000             50%  $1,000,000    Well-Structured     100%   $2,000,000

40%     $1,000,000             60%  $1,500,000    Average                 100%   $2,500,000

30%     $1,000,000             70%  $2,333,333    Poorly-Structured   100%   $3,333,333

20%     $1,000,000             80% $4,000,000     Poorly-Structured   100%   $5,000,000

Wow!  This shows the magnitude of the competitive advantage in development costs a company can have when it can produce well-structured, non-spaghetti software.   A very poorly-structured code base can easily have Lifetime Maintenance/Enhancement Costs that are double or triple those costs in a well-structured code base.

And, note that the curve of increasing dollar costs is exponential: As the Lifetime Maintenance/Enhancement Cost as a percentage of Total Lifetime Costs increases linearly (40%, 50%, 60%, etc.), the dollar costs of Lifetime Maintenance/Enhancement increase exponentially (an ever steepening curve), as shown below.

This makes it clear that investing more money in the initial development of a code base to ensure it is well-structured makes good business sense.  Extending the above example, what if 25% more money ($250,000) was invested in the initial development of the code to ensure the code was well-structured, thus avoiding the possibility of ending up with way above average “Lifetime Maintenance/Enhancement Cost” of 70% to 80%?  Perhaps a person with the right skill set to ensure this was hired, or consulted with, early on and the development took a little longer.  Here’s a scenario that shows the result of successfully aiming to have the Lifetime Maintenance/Enhancement Cost percentage at 50% of the Total Lifetime Cost to ensure a well-structured code base by spending 25% more in initial development, all other things being equal:

Cost of Initial                 Lifetime Maintenance /                   Total Lifetime Cost Development                  Enhancement Cost                            (TLC)

% TLC Dollar Cost            % TLC Dollar Cost                           % TLC Dollar Cost

50%   $1,250,000              50%   $1,250,000                             100%   $2,500,000

Increasing the initial development investment by 25% can result in a more well-structured code base that still costs far less during its lifetime than a poorly structured one (shown in the first table above with 70% and 80% numbers in the center column).

Even investing 50% more in initial development has a decent payoff, as shown below when compared with a very poorly structured code base with a Lifetime Maintenance/Enhancement Cost percentage of 80% of Total Lifetime Cost.

Cost of Initial                 Lifetime Maintenance /                   Total Lifetime Cost Development                  Enhancement Cost                            (TLC)

% TLC Dollar Cost            % TLC Dollar Cost                            % TLC Dollar Cost

50%   $1,500,000              50%   $1,500,000                             100%   $3,000,000

Please note from the above two examples that there is also a solid payback from significant refactoring of key parts of a poorly-structured code base early in its life.

But, the above numbers focus only on costs.  They do not account for the fact that well-structured code bases typically take much less time to get a given feature set to market than poorly-structured ones.  Therefore, investing more, either during initial development, or shortly thereafter, to produce a well-structured code base can decrease both lifetime costs and the time to market of all subsequent future releases. This makes ensuring a code base is well-structured even more compelling since it has a double pay back. The returns from a reduced time to market are explored below.

The development and maintenance/enhancement costs are the software production costs, i.e. the investment a business makes to produce the software over its life. Software production costs are just one factor in ROI, and the tip of the ice berg as it turns out.  The other key element in the Return on Investment from software is the functionality the software provides, and the expected and actual return from this functionality.

For a software product or Software-as-a-Service, the return on the investment to develop software is the revenue from paying customers.  Total revenue generated by a code base is the area under the curve of revenue over time.  Please keep this idea of “area under the revenue curve” in mind throughout this article.  As you may well know, in most businesses the revenue from sales of a software product should be so large that it dwarfs the costs of its production. This is because this revenue must pay for the non-software production costs of the business as well. Thus the “returns” part of ROI weighs even more heavily in the ROI calculation than software production costs.

An interesting, and sometimes fatal, twist in the returns from a software code base is this:  A code base provides both short and long term returns.  The short term return is revenue from selling the current release of the software now, e.g. this month or quarter.  The long term return on a code base is the revenue gained from future releases by adding new features and enhancing the functionality of the existing code base (the then current release).   Future releases with new features are produced to satisfy customer’s wants and needs, and to beat competing products.  Thus, the ability to deliver new features to customers requires building the new features on top of the existing code base. At the same time, the product sold now is exactly the same thing as the current long term business asset (code base) at that point.  This may not be self-evident to people coming from a non-software background, but it is the key to effectively managing a code base’s costs and returns as shown below.

Recall the difference in the elapsed time cost between poorly structured and well-structured code bases:  Adding new features to a poorly structured code base takes much longer than adding the same feature to a well-structured code.  And, the elapsed time to add such features gets worse and worse as more code is added to a poorly-structured code base over several releases without significant major refactoring.

Notice that when the elapsed time it takes to develop a new release starts significantly increasing with each subsequent release, it negatively impacts the potential future returns.  It pushes returns out further and further into the future, and could well prevent them from ever being realized.  A code base with such a “constantly expanding development time syndrome” not only delays revenue, it also gives competitors the opportunity to take current and potential new customers away from a business.  In general, the “expanding development time syndrome” decreases the competitive agility of a business, jeopardizes niche leadership, reduces potential returns, while at the same time it increases the costs of software production of new releases.  As you can see, the combination of these factors can have a very negative impact on a business, robbing the business of a significant share of the revenue the software code base could produce over its life.  (Here, visualize the area under the revenue curve as revenue declines due to customers delaying their purchases until they see the next release or buying a competitor’s product).  And, since the returns produced by the software are by far the largest factor in the ROI equation, this situation can make for really bad return on investment numbers.  When the “constantly expanding development time syndrome” clearly sets in a business is likely to either completely rewrite the software system requiring another large investment, or abandon that software product and/or niche.

To recap, the spaghetti code in a poorly structured code base causes two results:

  • The software takes longer to change than is good for the business in the market place.
  • Software changes costs a lot more than it has to over the entire life of the code base.

The combination of these two results of a poorly structured code base can prevent a business with the right product at the right time from fulfilling its sparkling potential, bogging it down in a sea of spaghetti code.

To generalize, software functionality and structure determine the lifetime ROI of a software system.  All other things being equal, software structure largely determines the cost of maintenance and enhancement, plus the time to market of all subsequent releases.  The functionality the software provides determines the returns, given that the software can be delivered with the right features, to the right customers, at the right time.  But, when the structure of the code base significantly impedes the time of subsequent deliveries of the right features, a business’s competitive agility is lost and the Return on Investment on the software goes wobbly.  Indeed, bad software structure can even cause business failures.

Here, you can see a way to maximize or optimize the business value of the software developed by a business:

Focus on the functionality required at the present time, knowing requirements will change in the future.  At the same time, ensure the software structure implementing this functionality is time and cost effectively flexible, extensible, and testable for both changing requirements and the timely production of new releases in the future.

Do this and you’ll have a very high value business asset:  A well-structured code base that will avoid the bad ROI of the “constantly expanding development time syndrome”.  A code base which has a high degree of competitive agility to quickly draw upon when needed, and which will have a longer life of generating substantial revenue.  And a code base in which your developers will be much more productive.  This is a simple formula for success, leveraging the proven results of today’s loosely coupled, extensible, flexible software structuring techniques that produce well-structured code bases.

Lastly I’d like to note that this article is fundamentally about software productivity, i.e. doing more with less.  I’ve omitted this term up till now so as not to confuse an already slippery subject.  Poorly structured code bases are anti-productive since they cause organizations to do less with more time and people.  Well-structured code bases are the opposite, and enhance the productivity of the entire business.

In future articles I will discuss perspectives and techniques for producing well-structured software.  I hope this article has given you a useful deeper understanding of the dynamics of software structure and its value to a business, and acts to broaden your perspective.

I have deliberately simplified everything by focusing upon these two items, so that it is clear how they interact.  There are other key variables in the software development process that come into play, but in my experience they are not usually strong enough by themselves to negate the effect of poor software structure.  One strong variable is the People Factor — Having the right people on a project has a very big impact.  Even so, over time even the best developers get bogged down by a poorly structured code base that undergoes little or no significant refactoring.

Two other key variables are the Process Factor and the Technology Factor (especially techniques, tools, and frameworks whose purpose is to aid in developing well-structured code bases).  It is these two variables that can make the key difference in producing well-structured software, given that both management people and developer people are committed to making them work their magic, and reaping their substantial rewards.


  1. “Manage Project Libraries with NuGet” by Phil Haack, MSDN Magazine, Vol 26, Number 11, November 2011, p 64. The author quotes from The Facts and Fallacies of Software Engineering, by Robert L. Glass, Addison-Wesley Professional, 2002.

Creative Commons License
dotnetsilverlightprism blog by George Stevens is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at

One Comment

Trackbacks & Pingbacks

  1. Working with Remote Developers – tom williamson

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: