9

In the Sun Java coding conventions document (here: http://www.oracle.com/technetwork/java/codeconv-138413.html), it states:

"80% of the lifetime cost of a piece of software goes to maintenance"

Does anyone know where this statistic is sourced from? I don't doubt the assertion, but I can make up statistics without attribution as well and I'd like to know where this came from before I start using it as a basis for other statements.

Dan Coates
  • 325
  • 1
  • 4

4 Answers4

7

You have to first define what maintenance means. Usually maintenance costs in excess of 50% include enhancement as well as defect removal.

The 80% figure doesn't seem to be directly attributable to a specific study, but you can find several credible figures in the > 50% range in the studies mentioned on this page: https://web.archive.org/web/20120313070806/http://users.jyu.fi/~koskinen/smcosts.htm

Table 3-7 of Applied Software Measurement, third ed. lists that of the 8200 projects studied, only 2410 were new developments. 1385 were maintenance projects, and the rest were enhancement projects. That corresponds to roughly 70% of projects that are maintaining existing code.

Joeri Sebrechts
  • 12,922
  • 3
  • 29
  • 39
5

Barry Boehm's Software Engineering Economics. And it's not 80% it's 50%-75%.

Chapter 30. Page 533-534.

http://www.amazon.com/Software-Engineering-Economics-Barry-Boehm/dp/0138221227

S.Lott
  • 45,264
  • 6
  • 90
  • 154
2

The 80-20 rule of thumb is very commonly invoked in many contexts, as concrete sample numbers standing in for the phrase "the large majority."

This may be just such an invocation.

yfeldblum
  • 1,532
  • 10
  • 9
-7

from Java Code Conventions - September 12, 1997 by Sun Microsystems.

You will see this quote in the introduction of the document under

1.1 Why Have Code Conventions

  • 80% of the lifetime cost of a piece of software goes to maintenance
  • Hardly any software is maintained for it's whole life by it's original author
  • Code conventions improve the readability of the software allowing engineers to understand new code more quickly and thoroughly
  • If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

By 2011, this document is quite dated. Software and systems are being developed in a multitude of languages including and excluding Java.

However, Java is very slow and has an extremely large memory footprint compared to C/C++. When some users experience how slow Java actually runs in comparison to other languages such as PHP, C/C++, etc, they often think that something is wrong with the program. Money is then spent on trying to improve performance to no avail. For this reason I always question people's motivation to jump on the titanic and set sail. As it does not make sense to implement many programs in Java, especially where performance or memory footprint is a concern.

I have actually seen people spend more time to implement something in Java for the sake of it being a Java implementation than they would have spent implementing the same software as a bash script on Linux or in Python or C++.

I'm not saying avoid Java at all costs, but there is a right tool for the right job and there are many many more tools than Java these days.

Congratulations to Apple for finally deprecating Java.!