software-maintenance on S Anand

Organisational amnesia

Tue, 19 May 2009 20:23:36 +0000

It’s amazing how much of a dependency there is on individuals writing IT systems. Reminds me of that Dilbert strip:

A few weeks ago, I was trying to figure out in what happens when there are multiple promotions. (Our client is a retailer.) I mean, if there’s a phone that costs £100 and there are 2 promotions: 10% off on phones and £10 off on phones. Do you apply the 10% off first and pay £80 or the £10 off and pay £81?

Funnily enough, the organisational answer is, “I don’t know.” The person who determined the logic is no longer with the firm. The person who wrote the code was a contractor and moved on to another project. The vendor hadn’t gotten around to documenting the code. Sure, the code’s there, and you just had to read it to figure out what it does. But no human knew what it was supposed to do.

Last week, there was a decision to rewrite some code that was 10 years old. A colleague who wasn’t quite involved in this work said, “I’m going to have to set aside 2-3 weeks for this. I wrote this stuff when I was a developer. The docs have vanished. The business owners have vanished. I’m the only one who has any clue on what it’s supposed to do.”

This week, we were trying to figure out how their store locator system works. After fiddling around with Fiddler, and seeing that it used Microsoft Virtual Earth, I was able to figure out that it identified stores near a location using a simple JSON API. But can we get the documentation around that? Nope. Tough luck. Nobody knows how it works any longer.

Personally, I don’t think this is unusual. We forget. Companies forget. But it’s usually good if what we forget is derivable. That’s how I got through my high-school physics exams: not by remembering stuff, but by being able to derive the stuff from a few principles.

Organisations can do the same. But to be able to do that, you need to have commonly understood principles. As Fred Brooks put it in The Mythical Man Month,

I contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

One of the biggest enemies of conceptual integrity is growth. Too many people too soon, and the important decisions are taken by people who’ve never had a long chat about things. There’s another reason not to grow too fast.

Comments

Kalpesh 20 May 2009 2:27 am: I guess, it should help having a debug log of things as the code is executed & the decision made in the code based on the data available. e.g. the code will put the log (conditionally) gave 10% discount, thus derived value of 90 (100 - 10) reducing $10 of the calculated value above = 80 (90 - 10) Basically, having a log of the sequence of steps, the state on which the code relies, input any function takes and output thereafter (but in a user understandable manner or in business language). One step closer to this could be writing code in a language that is relevant to business I feel we still write our code in terms of technology (arrays, exceptions, serializations etc). I don’t mean that we should not worry about those things. But, those things should be covered under a layer which makes easy for business people OR a new comer to come back to the code and read it like a specification.
Nagarjun 13 Dec 2009 10:50 am: We faced same situation while trying to find out how the comission is calculated. In the end it so happened that the commision was being calculated based on data that was 5 years old. Nobody had realised that the new data was not comin into the system :)

Programming theorems

Wed, 08 Nov 2006 12:00:00 +0000

Programming theorems.

The likelihood of Perl being involved in a system is directly proportional to the length of time the system has been in maintenance.

Every 5 minutes you spend writing code in a new language is more useful than 5 hours reading blog posts about how great the language is.

Think twice before presuming that CSV is a nice little easy file format. (see Leon)

Facts and Fallacies in Software Engineering

Tue, 22 Aug 2006 12:00:00 +0000

Facts in Software Engineering

People

The most important factor in software work is the quality of the programmers.
The best programmers are up to 28 times better than the worst programmers.
Adding people to a late project makes it later.
The working environment has a profound impact on productivity and quality.

Tools and Techniques

Hype (about tools and techniques) is the plague on the house of software.
New tools/techniques cause an initial loss of productivity/quality.
Software developers talk a lot about tools, but seldom use them.

Estimation

One of the two most common causes of runaway projects is poor estimation.
Software estimation usually occurs at the wrong time.
Software estimation is usually done by the wrong people.
Software estimates are rarely corrected as the project proceeds.
It is not surprising that software estimates are bad. But we live and die by them anyway!
There is a disconnect between software management and their programmers.
The answer to a feasibility study is almost always “yes”.

Reuse

Reuse-in-the-small is a well-solved problem.
Reuse-in-the-large remains a mostly unsolved problem.
Reuse-in-the-large works best for families of related systems.
Reusable components are three times as hard to build, and should be tried out in three settings.
Modification of reused code is particularly error-prone.
Design pattern reuse is one solution to the problems of code reuse.

Complexity

For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.

Requirements

One of the two most common causes of runaway projects is unstable requirements.
Requirements errors are the most expensive to fix during production.
Missing requirements are the hardest requirements errors to correct.

Design

Explicit requirements “explode” as implicit (design) requirements for a solution evolve.
There is seldom one best design solution to a software problem.
Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal.

Coding

Designer “primitives” (solutions they can readily code) rarely match programmer “primitives”.
COBOL is a very bad language, but all the others (for business applications) are so much worse.

Error-removal

Error-removal is the most time-consuming phase of the life cycle.

Testing

Software is usually tested at best at the 55-60 percent (branch) coverage level.
100 percent coverage is still far from enough.
Test tools are essential, but many are rarely used.
Test automation rarely is. Most testing activities cannot be automated.
Programmer-created, built-in, debug code is an important supplement to testing tools.

Reviews/Inspections

Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
But rigorous inspections should not replace testing.
Post-delivery reviews (some call them “retrospectives”) are important, and seldom performed.
Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

Maintenance typically consumes 40-80 percent of software costs. It is probably the most important life cycle phase of software.
Enhancements represent roughly 60 percent of maintenance costs.
Maintenance is a solution, not a problem.
Understanding the existing product is the most difficult task of maintenance.
Better methods lead to MORE maintenance, not less.

Quality

Quality IS: a collection of attributes.
Quality is NOT: user satisfaction, meeting requirements, achieving cost/schedule, or reliability.

Reliability

There are errors that most programmers tend to make.
Errors tend to cluster.
There is no single best approach to software error removal.
Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

Efficiency stems more from good design than good coding.
High-order-language code can be about 90 percent as efficient as comparable assembler code.
There are tradeoffs between size and time optimization.

About Research

Many researchers advocate rather than investigate.

Fallacies in Software Engineering

About Management

Fallacy: You can’t manage what you can’t measure.
Fallacy: You can manage quality into a software product.

People

Fallacy: Programming can and should be egoless.

Tools and Techniques

Fallacy: Tools and techniques: one size fits all.
Fallacy: Software needs more methodologies.

Estimation

Fallacy: To estimate cost and schedule, first estimate lines of code.

Testing

Fallacy: Random test input is a good way to optimize testing.

Reviews

Fallacy: “Given enough eyeballs, all bugs are shallow”.

Maintenance

Fallacy: The way to predict future maintenance cost and to make product replacement decisions is to look at past cost data.

About Education

Fallacy: You teach people how to program by showing them how to write programs.

These are from Robert Glass’ book Facts and Fallacies in Software Engineering.