At the recent Melbourne Patterns Group (that I blogged about here) Gian Lorenzetto lent me a copy of the book Implementation Patterns by Kent Beck and Chapter 4 of the book is called “Motivation”. This chapter is a great description of the “costs” of software development and I wanted to share it with you. If you can find a better description then please let me know about it.
“Chapter 4 Motivation
Thirty years ago Yourdon and Constantine in Structured Design identified economics as the underlying driver of software design. Software should be designed to reduce its overall cost. The cost of software is divided into the initial cost and the cost of maintenance:
cost total = cost develop + cost maintain
Once the industry gained experience with software development, it was a big surprise to many that the cost of maintenance is much higher than the cost of initial development. (Projects with little or no maintenance should use a very different set of implementation patterns from those presented in the remainder of this book.)
Maintenance is expensive because understanding existing code is time consuming and error-prone. Making changes is generally easy when you know what needs changing. Learning what the current code does is the expensive part. Once the changes are made, they need to be tested and deployed.
cost maintain = cost understand + cost change + cost test + cost deploy
One strategy for reducing the overall cost is to invest more in initial development in hope of reducing or eliminating the need for maintenance. Such efforts have generally failed to reduce overall costs. When code needs to change in unanticipated ways, no amount of forethought can perfectly prepare the code for change. The premature attempts to make the code general enough to meet the future needs often interfere with the unanticipated changes that turn out to be necessary.
Substantially increasing the up-front investment in software runs counter to two important economic principles: the time value of money and the uncertainty of the future. Since a dollar today is worth more than a dollar tomorrow, in principle and implementation strategy should generally encourage deferring costs. Also, because of uncertainty an implementation strategy should generally take immediate benefits in preference over possible long term benefits. While this may sound like an license to hack without regard for the future, the implementation patterns are focused on ways to gain immediate benefit while setting up clean code for ease of future development.
My strategy for reducing overall costs is to ask all programmers to address the cost of understanding code during the maintenance phase by focusing on communicating, programmer-to-programmer. The immediate benefits of clear code are fewer defects, easier sharing of code, and smoother development.
Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts.”