Book Excerpt Software Maintenance is a Solution, Not a Problem (An Excerpt from Software Conflict 2.0) Excerpted from Software Conflict 2.0: The Art and Science of Software Engineering, from developer.* Books ISBN: 0977213307 Pages: 308 Price: $29.95 U.S. / UK£22.99 Publication Date: March 10, 2006 Publisher: developer.* Books March 10, 2006 20% Off the Cover Price in the US! Other Options: Amazon US * Amazon UK * B&N * More Is software maintenance a problem? Today's standard answer is "You bet it is." The standard rationale for that standard answer is "Look how much of our budget we're putting into software maintenance. If we'd only built the software better in the first place, we wouldn't have to waste all that money on maintenance." Well, I want to take the position that this standard answer is wrong. It's wrong, I want to say, because the standard rationale is wrong. The fact of the matter is, software maintenance isn't a problem, it's a solution! What we are missing in the traditional view of software as a problem is the special significance of two pieces of information: The software product is "soft" (easily changed) compared to other, "harder," disciplines. Software maintenance is far less devoted to fixing errors (17 percent) than to making improvements (60 percent). In other words, software maintenance is a solution instead of a problem because in software maintenance we can do something that no one else can do as well, and because when we do it we are usually building new solutions, not just painting over old problems. If software maintenance is seen as a solution and not as a problem, does that give us some new insight into how to do maintenance better? I take the position that it indeed does. The traditional, problem-oriented view of maintenance says that our chief goal in maintenance should be to reduce costs. Well, once again, I think that's the wrong emphasis. If maintenance is a solution instead of a problem, we can quickly see that what we really want to do is more of it, not less of it. And the emphasis, when we do it, should be on maximizing effectiveness, and not on minimizing cost. New vistas are open to us from this new line of thinking. Once we take our mindset off reducing costs and place it on maximizing effectiveness, what can we do with this new insight? The best way to maximize effectiveness is to utilize the best possible people. There is a lot of data that supports that conclusion. Much of it is in the "individual differences" literature, where we can see, for example, that some people are significantly better than others at doing software things: Debugging: some people are 28 times better than others. Error detection: some people are 7 times better than others. Productivity: some people are 5 times better than others. Efficiency: some people are 11 times better than others. The bottom line of these snapshot views of the individual differences literature is that there is enormous variance between people, and the best way to get the best job done is to get the best people to do it. This leads us to two follow-on questions: Does the maintenance problem warrant the use of the best people? Do we currently use the best people for doing maintenance? The first question is probably harder to answer than the second. My answer to that first question is "Yes, maintenance is one of the toughest tasks in the software business." Let me explain why I feel that way. Several years ago I coauthored a book on software maintenance. In the reviewing process, an anonymous reviewer made this comment about maintenance, which I have remembered to this day: Maintenance is: intellectually complex (it requires innovation while placing severe constraints on the innovator)

technically difficult (the maintainer must be able to work with a concept and a design and its code all at the same time)

unfair (the maintainer never gets all the things the maintainer needs. Take good maintenance documentation, for example)

no-win (the maintainer only sees people who have problems)

dirty work (the maintainer must work at the grubby level of detailed coding)

living in the past (the code was probably written by someone else before they got good at it)

conservative (the going motto for maintenance is "if it ain't broke, don't fix it") My bottom line, and the bottom line of this reviewer, is that software maintenance is pretty complex, challenging stuff. Now, back to the question of who currently does maintenance. In most computing installations, the people who do maintenance tend to be those who are new on the job or not very good at development. There's a reason for that. Most people would rather do original development than maintenance because maintenance is too constraining to the creative juices for most people to enjoy doing it. And so by default, the least capable and the least in demand are the ones who most often do maintenance. If you have been following my line of reasoning here, it should be obvious by now that the status quo is all wrong. Maintenance is a significant intellectual challenge as well as a solution and not a problem. If we want to maximize our effectiveness at doing it, then we need to significantly change the way in which we assign people to it. I have specific suggestions for what needs to be done. They are not pie-in-the-sky theoretical solutions. They are very achievable, if management decides that it wants to do them: Make maintenance a magnet. Find ways to attract people to the maintenance task. Some companies do this by paying a premium to maintainers. Some do this by making maintenance a required stepping stone to upper management. Some do this by pointing out that the best way to a well-rounded grasp of the institution's software world is to understand the existing software inventory. Link maintenance to quality assurance. (We saw this in the previous essay.) Plan for improved maintenance technology. There are now many tools and techniques for doing software maintenance better. (This has changed dramatically in the last couple of years.) Training and tools selection and procurement should be high on the concerned maintenance manager's list of tasks. Emphasize "responsible programming." The maintainer typically works alone. The best way to maximize the effectiveness of this kind of worker is to make them feel responsible for the quality of what they do. Note that this is the opposite of the now-popular belief in "egoless programming," where we try to divest the programmer's personal involvement in the final software product in favor of a team involvement. It is vital that the individual maintainer be invested in the quality of the software product if that product is to continue to be of high quality. There they are...four simple steps to better software maintenance. But note that each of those steps involves changing a traditional software mindset. The transition is technically easy, but it may not be socially or politically quite so easy. Most people are heavily invested in their traditional way of looking at things. If we are to get there at all, however, there is one vital first step which must be taken. It is the step that started off this essay. We must see that software maintenance is a solution, not a problem. If we agree to that, then we have opened the door to profound changes in how we software people do our business. Think about it. ### Copyright ©2006, Robert L. Glass. Published by developer.* Books. Purchase direct from the publisher at 20% Off the Cover Price in the US!

Or purchase from Robert L. Glass held his first job in computing in 1954. Author of over 25 books, he is one of the true pioneers of the software field. He is the editor and publisher of The Software Practitioner, and also writes regular columns for Communications of the ACM and IEEE Software. In 1995 he was awarded an honorary Ph.D. from Linkoping University of Sweden, and in 1999 he was named a Fellow of the ACM professional society. His unique viewpoint and timeless writings have for decades offered insights to practitioners, managers, professors, entrepreneurs, researchers, and students alike. Or purchase from Amazon US Amazon UK , or wherever books are sold.

Order Now!

Gerald M. Weinberg Over the years, in the software business, there have only been a handful of writers consistently worth listening to. Bob Glass is one of these rare individuals. If you care about your profession, listen to what he has to say. Software Conflict 2.0 Glass presents insights from some of the timeless debates between the sharpest practitioners and researchers in the field.

Karl E. Wiegers, Principal Consultant at Process Impact, author of Software Requirements, 2nd Edition Robert Glass has spent decades as an astute observer of the software industry. InGlass presents insights from some of the timeless debates between the sharpest practitioners and researchers in the field. He brings rare gifts to our profession: intelligence, knowledge, insight, a keenly critical eye, and a shining honesty...Robert L. Glass is a wise man in a field critically short of substance and long on hype.

Edmund Arranga The Mark Twain of the computer industry.

Doug King Entertaining, informative, and thought-provoking...There is food for thought for everyone, and if the book stirs controversy, then I suspect it has achieved its purpose.

Professor Daniel E. Cooke, International Journal of Software Engineering and Knowledge Engineering

Andrew Hunt, from the Foreword Bob's essays focus on the realities facing practitioners. The author has the knack for getting to the essence of an issue and offers many novel insights...lucid and witty.

Don Chand, Computing Reviews Facts About Bob Glass A 50+ year veteran software practitioner and researcher Author or editor of over 25 books and over 90 professional papers Author of regular columns in IEEE Software and Communications of the ACM A Fellow of the ACM professional society The Software Practitioner newsletter. Editor and publisher ofnewsletter. Editor Emeritus of the Journal of Systems and Software Learn More About Robert L. Glass Learn More About developer.* Books