As Easy as Pi

Software Maintenance Blog

William A Clements

As Easy as Pi

or π or 3.1415926535897932384626433832795… or 22⁄7, 223⁄71, 355⁄113 [[1]]

“How though, are pies thought to be easy? They aren't especially easy to make; I know, I've tried it.” [[2]]

With in the first few week of working out side the academic world, I was asked to work on fixing code. My boss asked me to work on several tasks, and to tell him how long it would take. Since I was new to the large software, and had no experience in estimating how long any of the tasks would take, I estimated 2-6 week for each of the tasks. 2 week for a problem that I could reproduce. 4 weeks for adding new features. And 6 weeks for problems that involved removing code and problems that I could not immediately reproduce. Let just say this I did not get any awards for my estimations.

How long does it take to do software maintenance? Any smart programmer, contractor, or professional, will say, “That depends! What is the problem?” Most professionals, (i.e.: general contractor, plummer, car mechanic) I have come across will not get cornered in say how long something will take until they have looked in to it further. Most professionals will not start a task until they understand the whole problem. It is kind of like starting a home improvement project and half way through you realize that you do not have the tools to complete the task. Understanding the whole problem is the problem in most cases.

Scotty: Do ye mind a little advice? Starfleet captains are like children. They want everything right now, and they want it their way. But the secret is to give only what they need, not what they want!

Geordi: Yeah, well I told the captain I'd have this analysis done in an hour.
Scotty: And how long would it really take?
Geordi: An hour!
Scotty: Oh, ye didn't tell him how long it would really take, did ye?
Geordi: Well, of course I did.
Scotty: Oh, laddie, ye've got a lot to learn if ye want people to think of ye as a miracle worker! [[3]]

“How long will this take?”

Rule 1: Investigate first, then solve.

My answer, “I need at least XX days to investigate the problem:
- 2-4 day to understand the architecture
- 2-4 day to play with the software
- 4-8 days to figure out the problem.

Then I will give you an answer on how long it will take to fix the problem.”

Rule 2: Multiply by Pi

Or any other factor, but never what you think it is. To use another Star Trek euphemism:

Kirk: “How long to re-fit?”
Scotty: “Eight weeks. But you don’t have eight weeks, so I’ll do it for you in two.”
Kirk: “Do you always multiply your repair estimates by a factor of four?”
Scotty: “How else to maintain my reputation as a miracle worker?”
Kirk: “Your reputation is safe with me.”
– From Star Trek III [[4]]

No matter how long you think it will take, it will never take that long. What mother actually delivers on her due date? It is better to over estimate, and be the miracle worker, then under estimate and be the “weakest link”.

Rule 3: Record it

Keep a record of how long it takes you to do different software maintenance tasks. This will give you a ball park for estimating. Also keep a record of things that you learned from other people’s code.

---

[1] http://en.wikipedia.org/wiki/Pi
[2] http://www.phrases.org.uk/meanings/as-easy-as-pie.html
[3] http://www.c2.com/cgi/wiki?DiscordantRewardMechanisms , Star Trek: The Next Generation - Relics (1992)
[4] “What Scotty from Star Trek Can Teach Us About Managing Expectations”, Scott Vandehey http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

The Winchester Mystery House and Legacy Software

Software Maintenance Blog

William A Clements

The Winchester Mystery House[1] and Legacy Software

“The Winchester Mystery House is a well-known California mansion that was under construction continuously for 38 years, and is reported to be haunted. It once was the personal residence of Sarah Winchester, the widow of gun magnate William Wirt Winchester, but is now a tourist attraction. Under Winchester's day-to-day guidance, its "from-the-ground-up" construction proceeded around-the-clock, without interruption, from 1884 until her death on September 5, 1922, at which time work immediately ceased.[2] The cost for such constant building has been estimated at about US $5.5 million[3] (if paid in 1922, this would be equivalent to almost $70 million in 2008 dollars).[4]
Figure 2: Aerial View

The mansion is renowned for its size and utter lack of any master building plan. According to popular belief, Winchester thought the house was haunted by the ghosts of individuals killed by Winchester rifles, and that only continuous construction would appease them. It is located at 525 South Winchester Blvd. in San Jose, California. […]
Figure 3: Stairs to Ceiling


There are about 160 rooms, including 40 bedrooms and two ballrooms, one completed and one under construction. The house also has 47 fireplaces, 10,000 window panes, 17 chimneys (with evidence of two others), two basements and three elevators. ”[5]

Some of the most interesting part of the house, is there are staircases that lead to the ceiling, doors that open to walls, or worse, to the outside three stories up.

“What the $#!^? This code doesn’t go anywhere!”
Legacy Code with out a master plan in software maintenance will eventually end up in much like the Winchester House. Without careful management of the four categories of maintenance (Corrective, Adaptive, Perfective, Preventive), the code could easily have areas that doesn’t lead to anywhere. For example, adding new functionality, without removing or replacing old functionality from the code. If not all the t’s are crossed, and i's dotted, and all the piece removed, legacy code can be come blotted, and unworkable.

---

[1] http://www.winchestermysteryhouse.com/
[2] A Mystery House, Frommer's San Jose, retrieved Oct. 30, 2006.
[3] Amazing Facts, Winchester Mystery House, retrieved Nov. 7, 2007
[4] CPI Inflation Calculator, Bureau of Labor Statistics, retrieved Nov. 19, 2007
[5] http://en.wikipedia.org/wiki/Winchester_Mystery_House

The Art of Software Maintenance

Software Maintenance Blog

William A Clements

The Art of Software Maintenance
            Not to be confused with the Art of the Motorcycle Maintenance, this entry is about an article I recently read. I have found that when you have come up with a good way of explaining something, someone always has a better way. “The Art of Maintenance Programming” by Nemanja Trifunovic explain nine practices every software maintenance engineer should strive to master. In summary:

• Get to Like It
• Disadvantage: “Developers dream of being chief architects in their teams, and when they end up maintaining existing software, it feels almost like punishment.”
• Advantage: “…Employers actually value people who solve problems; and maintenance programming can be a good chance to demonstrate your problem-solving skills”
• Get Familiar with the Functionality of the Software You Maintain 
• Read the existing documentation 
• Dig out the test plan, and go through it 
• Find out how the software is being used 
• If you are a power user of the software you maintain, chances are you will spend less time in the debugger 
• Get Familiar with the Architecture of the Software You Maintain 
• You would expect to inherit detailed and up-to date design documentation, including requirements, functional specifications, high-level and low-level design, as well as well-commented code, right? – Ah Nope 
• Look at the code 
• Try to understand the roles of classes, modules and components
• Use the debugger 
• Step through different scenarios of use
• Be sure to write down your findings and organize them in some form
• It can be some formal method like UML diagrams, or something informal but easy to understand
• Communicate with the Users
• When they report a problem, get back to them immediately, even if you don’t have a solution at that moment – just let them know you are looking into it and not ignoring them. Keep them updated about the status of their problem. Finally, be honest; if you can’t meet their request for any reason, tell them.
• If Possible, Communicate with Original Developers
• Don’t expect them to do the actual coding for you, but they can throw you an idea how to accomplish something, explain you why something works the way it works, and provide you with lots of helpful hints.
• Keep the History of Changes
• An accurate history of changes is invaluable for successful maintenance, even if nobody else before you took care of it, and you get only a partial list of changes.
• Be Conservative
• Many times during the maintenance work, you are going to get frustrated with the existing code in some module, and just want to toss it away and rewrite it from scratch. Before you actually do that, ask yourself some questions:
•  How would it benefit your organization and its customers? The fact that some code is ugly, or looks ugly to you is not per se a reason to rewrite it. If a customer wants a feature that can’t be added to existing code, that could be a reason to consider rewriting it. 
• Are you sure you understand what this code does and how it works? 
• Are you sure you understand how it interacts with other parts of the system, and which modules and functionality depend on the code you want to rewrite? 
• Are you sure you can make it better? Maybe you run into the same problems the original developers did, and make it same or even worse.
• Refrain from refactoring
• Try to do it the right way immediately, later will never come. 
• Test after Every Change You Make
• First coding task you need to do after taking some software to maintain is to write a comprehensive regression-test suite.
• A good practice is that for each defect report you get, write a test-case to reproduce it.
• Adopt Existing Code Conventions Even If You Don’t Like Them
• Try to stick to whatever conventions exist in the code you maintain, … don’t introduce yet another one

In my own experience, I have learned each of these principles, sometimes I learn them the easy way, others the hard, and they are extremely helpful in keeping the software from turning into spaghetti code.

I’m a developer; there is no money in maintenance.

Software Maintenance Blog

William A Clements

“I’m a developer; there is no money in maintenance.”

Beside self made programmers, most schools, universities are producing program developer who develops code more and more efficiently.

• Where does all that code end up?
• What happen to the program when it needs to be fixed?

It ends up in the world of software maintenance.

The following chart represents the cost of software maintenance compared to the entire cost of life of a program. The relative cost for maintaining software and managing its evolution now represents more than 90% of its total cost. Various studies on this subject are described in Table 1.

Table 1. Proportional software maintenance costs for its supplier. [[1]]

Year	Proportion of software maintenance costs	Definition	Reference
2000	>90%	Software cost devoted to system maintenance & evolution / total software costs	Erlikh (2000)
1993	75%	Software maintenance / information system budget (in Fortune 1000 companies)	Eastwood (1993)
1990	>90%	Software cost devoted to system maintenance & evolution / total software costs	Moad (1990)
1990	60-70%	Software maintenance / total management information systems (MIS) operating budgets	Huff (1990)
1988	60-70%	Software maintenance / total management information systems (MIS) operating budgets	Port (1988)
1984	65-75%	Effort spent on software maintenance / total available software engineering effort.	McKee (1984)
1981	>50%	Staff time spent on maintenance / total time (in 487 organizations)	Lientz & Swanson (1981)
1979	67%	Maintenance costs / total software costs	Zelkowitz et al. (1979)

Table 2: Evolution of maintenance costs. [[2]]
Reference	Year	% Maintenance
Lientz and Swanson (1980)	1976	60%
Pigoski, (1996)	1980-1984	55%
Schach (1990)	1987	67%
Pigoski (1996)	1985-1989	75%
Frazer (1992)	1990	80%
Pigoski (1996)	90’s (prev.)	90%

---

[1] http://users.jyu.fi/~koskinen/smcosts.htm

[2] Polo, Piattini, and Ruiz; “Advances in Software Maintenance Management – Technologies and Solutions”, Idea Group Publishing, London 2003 http://skillport.books24x7.com

What is the name of the song?

Software Maintenance Blog

William A Clements

What is the name of the song?
      In my undergraduate Programming Language class, we, the class, were able to get the professor off on a side tangent. On one of these occasions, the professor referenced a scene in “Through the Looking Glass” by Lewis Carroll. As some of you might know Lewis Carroll mostly wrote mathematic books, except for Alice in Wonderland series, which has several mathematic under tones, one of which I am about to point out.
      In the scene, Alice is walking with the White Knight, and they have just finished coming to end of woods. Alice’s expression are mis-interrupted by the Knight:

“Alice could only look puzzled: she was thinking of the pudding.
`You are sad,' the Knight said in an anxious tone: `let me sing you a song to comfort you.'
`Is it very long?' Alice asked, for she had heard a good deal of poetry that day.
`It's long,' said the Knight, `but it's very, very beautiful. Everybody that hears me sing it -- either it brings the tears into their eyes, orelse --'
`Or else what?' said Alice, for the Knight had made a sudden pause.
`Or else it doesn't, you know. The name of the song is called "Haddocks' Eyes".'
`Oh, that's the name of the song, is it?' Alice said, trying to feel interested.
`No, you don't understand,' the Knight said, looking a little vexed. `That's what the name is called. The name really is "The Aged Aged Man".'
`Then I ought to have said "That's what the song is called"?' Alice corrected herself.
`No, you oughtn't: that's quite another thing! The song is called "Ways and Means": but that's only what it's called, you know!'
`Well, what is the song, then?' said Alice, who was by this time completely bewildered.
`I was coming to that,' the Knight said. `The song really is "A-sitting On a Gate": and the tune's my own invention.'
So saying, he stopped his horse and let the reins fall on its neck: then, slowly beating time with one hand, and with a faint…”[ ]

       The knight pointed out four ways of identifying something. The following example pointed out the differences in these four measures of identification. The first example identifies our national anthem. The second example is what one would see in typical programming language of an assignment of an variable. The third example represents the different definitions/scope of an object in Object Oriented Programming.

Four Definitions	Example 1	Example 2(int A = 2;)	Example 3 (OO)
The name of the song is called	National Anthem	Integer	Declaration
The name is called	Song	A	Instance
The song is called	“Oh say can you see”	Value/Variable	Definition
The song is	America the Beautiful	2 or Number	Symbolizes

Table 1: Illustration of Lewis Caroll's four different definitions

Software Maintenance? Didn’t they teach you that in school?

Software Maintenance? Didn’t they teach you that in school?
You just graduated from school last week in Computer Science to be a developer, and it is you second week on your new “high paying” [ah!] entry level job. You boss just ask you to go and fix this bug that the customer just found, thinking it would be a good idea to get introduced to the software system that was written before you were born. Oh, and he want to know how long it will take to fix it. You tell him that you don’t know to fix other peoples code nor how long it would take. He ask, “Why not, didn’t they teach you that in school?”

Purpose
The purpose of this blog is to identify tools, techniques, and methodologies to improve the peon programmer, like myself, ability to solve software maintenance problems.

Overview of Software Maintenance
Since the invention of “HelloWorld” there has been software maintenance. It has gone by different names, from debugging, operations and maintenance, operations & support, new features, etc. But purpose has stay the same, fix problems with existing code and/or add new features with out adding new problems.

E.B. Swanson[1] initially identified three categories of maintenance: corrective, adaptive, and perfective. These have since been updated and ISO/IEC 14764 presents:
• Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems.
• Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.
• Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability.
• Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.

Why should I learn to do software maintenance?
Have you ever had to read you own code from six month ago? Have you ever had to review someone else’s code? Have you had to read documentation about you favorite software, and discovered it is not up to date? Have you had to use freeware, and make modification? If so, you have done software maintenance.

Reference
1. http://en.wikipedia.org/wiki/Software_maintenance

WorkingEffectivelyWithLegacyCode

Working Effectively with Legacy Code (Robert C. Martin Series) (Paperback)
From the Back Cover

Get more out of your legacy systems: more performance, functionality, reliability, and manageability

Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.

In this book, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material Michael created for his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds of developers, technical managers, and testers bring their legacy systems under control.

The topics covered include

* Understanding the mechanics of software change: adding features, fixing bugs, improving design, optimizing performance
* Getting legacy code into a test harness
* Writing tests that protect you against introducing new problems
* Techniques that can be used with any language or platform—with examples in Java, C++, C, and C#
* Accurately identifying where code changes need to be made
* Coping with legacy systems that aren't object-oriented
* Handling applications that don't seem to have any structure

This book also includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes.
Product Details

* Paperback: 456 pages
* Publisher: Prentice Hall PTR (September 22, 2004)
* Language: English
* ISBN-10: 0131177052
* ISBN-13: 978-0131177055
http://www.amazon.com/exec/obidos/ASIN/0131177052/codinghorror-20


http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf