Development cost versus maintenance cost [closed]

Question

I'm trying to explain the ratio of development versus maintenance costs to our sales department, and currently I have mostly my gut feeling that we spend about 60% of the time with maintenance.

We have some persons on the team who tends to sell custom solutions, that we have to build, and if the sales people doesn't understand the total cost of development, then they will not be able to sell for realistic prices.

Another "problem" is that we are expanding our service, and have a need to refactor some of the underlying infrastructure in order to reduce time to market and other measure points.

Do you have any good suggestions on what I should refer to in order to build a solid argument? And what points should I bring up in order to give them a good understanding of the problem?

Maybe there is some great text out there somewhere that I can point to.

Answer 1

In "Frequently Forgotten Fundamental Facts about Software Engineering" by Robert L. Glass, (an article in IEEE Software May/June 2001), He talks about softwares "60/60" rule, that is that maintenance typically consumes 40 to 80% (60% average) of software costs, and then that enhancement is responsible for roughly 60% of software maintenance costs, while error correction is about 17%.

Answer 2

After 29 years in the industry I can say Maintenance is 60-80% of total cost. Development is at most 20%. But most companies today don't seem to acknowledge that they put the most focus on fast development and set due dates without proper estimation. This forces developers to dump and go, which only makes the maintenance harder. So what do the execs do as a result? They throw away all in-house software and buy 3rd party stuff. Then the nightmare of system integration happens and maybe 4 or 5 years later they will kind-of, sort-of get it all working but the cost to do that is exponentially higher than spending the time up front and doing it right the first time. In the meantime all the seasoned old timers hang up their hats and a new breed of young bucks fly in with the attitude of "we can fix anything". And that, my friend is what they'll be doing for a long time.

This is why Agile eventually won me over because waterfall just doesn't work in software. Never has and never will. It's all about smaller working iterations and parts development. Just like Henry Ford showed us in 1900...