Categories: managerial

The impulse to constantly add new and incremental features to a software program certainly isn’t unique to modern software develoment, or to a particular technology or methodology. It derives largely from three sources. Upper management and marketing want, and sometimes need, those additional features to win a customer, to better position the product against a competitor, or to better justify the expense of an in-house project. Engineers often find it far more fun, more interesting, and more rewarding to add or extend features than to make existing features work completely and perfectly. And customers supply a constant flow of demand for new and improved functionality.

The problem is that many modern technologies and methodologies intensify all these tendencies. With a decent software design and implementation, based on current technology, it can take literally only a few minutes to add or extend features. Frankly, that’s the payoff that lures many engineers to modern technologies in the first place: They get to do really neat stuff, do it quickly, and impress the boss while they’re at it. The boss, having seen how quickly engineers can extend or create functionality, doubles or trebles the list of must-have features. The technical manager, caught in the middle, wonders how to deal with all this.

Symptoms

Engineers focusing on adding new features instead of getting old ones working completely. Upper management passing down long (or even short) lists of additional features when the engineering schedule will be hard-pressed to accommodate the current ones. Customers failing to distinguish between what they’d like and what they’re willing to live with.

Consequences

Features that don’t work as completely or well as they were intended. Missed milestones and schedule slippage.

Detection

Review all existing features with the engineering team and get an honest assessment of where each feature is and what it will take to complete it. If necessary, do a design and code review for each feature. Compare the documented “essential features” list—and the schedule required to complete them—with the current feature set as well as those proposed by engineers and upper management, and find where the differences are coming in.

Extraction

Nothing fancy here: Get the absolute “drop dead” release date for the software and work backward from there, allocating time to design, implement, debug, and test each feature that is not yet completed. Show everyone (especially customers) the gap between the time and resources allocated those required for just the currently planned and requested features. Use whatever process works in your company for performing feature triage: keeping those that are absolutely essential, dropping those that can wait for the next release, and negotiating on the others.

Prevention

Use the process given in Extraction before a line of code is ever written. As features are proposed, collect them in a list, but do not allow any work on them. At intervals, repeat the process: You might have time (or need) to schedule some of the proposed features, but you may well have to drop previously required ones.

As with a prior pitfall on features, this pitfall is so an obvious and well-known that I’m almost embarrassed to include it here. Again, it is still so common that I must.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

Categories: managerial

Let’s start by freely acknowledging that, with rare exceptions, software of any complexity changes between original specification and actual delivery. This is to be expected, and to a certain extent encouraged, when the changes represent a refinement of our understanding of the problem domain and the required solutions. Hence Brooks’ assertion that we must be prepared to “throw one away” — we just don’t know for sure what we’ll need to build and how to build it until we’ve built one. One of the advantages of modern technologies and methodologies is that such changes and adaptations can often be made readily and at lower cost in time and risk than for earlier development approaches.

Let’s also acknowledge that, given the time required to deliver a significant piece of software, customer requirements, technical expectations, and market conditions may change dramatically between the time a project is specified and when it is delivered. As John Donovan noted many years ago, the distance between the leading edge of technology and the trailing edge appears to be constantly shrinking. You may need to redirect or revamp projects as they go along in order to respond to such shifts.

But that’s not what this pitfall is about. This pitfall is about specifications that aren’t nailed down, or that aren’t firmly specified at all. A given feature or aspect of the project is discussed (or maybe it isn’t). As time goes on, the person(s) implementing it have one idea as to what it means or may even have new and improved ideas for it. Those not implementing it may be assuming something quite different from what is being written. Those not involved—including, and especially, upper management—may have quite a different (and erroneous) idea of what the feature will be. And customer expectations may be something else again. When the time comes for feature completion, code integration, project review, or customer acceptance, all hell breaks loose.

Symptoms

Lack of specification documentation. Engineers showing off “new features.” Mismatched subsystems. Constant delays in completing given features.

Consequences

Schedule slips due to ever-changing specification and integration problems. Lack of management, marketing, or customer acceptance of the delivered project.

Detection

First, see whether you can put your hands on a detailed list of features. If no such list exists or if it is incomplete or vague, then you have problems.

Second, see whether you can find a detailed description for each feature, including clear information about what it will not do. Missing or incomplete information is another danger sign.

Third, compare the specification against what is actually being implemented. Variations are yet another indication of trouble.

Fourth, propose a change in specification and see what is the process for making it. The more informal and undocumented the process, the greater the danger of this pitfall.

Extraction

The Detection exercise should give you a good idea about your current state and how to get out of it: Produce the documents described and then use them as a hard spec for the project.

A second (not necessarily exclusive) approach is to write a complete user’s manual for the project and let that be the final specification. This is what we did many years ago at Pages Software: the user documentation, complete with screen shots, was printed a full nine months before the product was released. The president and CEO of Pages gave a copy to every engineer and said, “Here’s the final specification.” It saved all of us from the temptation of making further changes.

Prevention

Establish a process to create, review, modify, and enforce the specification. This is, in effect, the documentation of the design phase of your methodology. This process won’t be easy or popular, but it will pay off significantly in the long run.

This is such an obvious and well-known pitfall that I’m almost embarrassed to include it here. But it is still so common that I must.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

Categories: political

A particular technology or methodology (the “TOM”) is wonderful. At least, you think it is, based on anything from a breathless magazine article to years of experience with solid, successful software development using this TOM. Or you may not think it’s wonderful, but you do think it may offer advantages and benefits to your development efforts. And, of course, what’s obvious to you should be obvious—or, at least, understandable—to everyone else.

So you blithely push ahead…until people start pushing back. And before you know it, you’re engaged in a political battle, fighting resistance to the TOM that may range from guerrilla sniping to a full frontal assault.

Why might people resist accepting object technology? The reasons are varied and may range from the well-founded to the completely irrational to the deliberately obstructionist. Here are examples:

• They don’t understand the TOM.
• They don’t want to understand the TOM.
• They’re afraid they won’t be able to understand the TOM (and thus will have less value to the company).
• They know they won’t be able to understand the TOM, because they’ve been just skating by for the last ten years–taking advantage of the IT job shortage–and know that this will expose them for what they are.
• They have very strong feelings about the language and/or programming methodology, or tools or all three that they currently use.
• They really detest the TOM and/or the associated language and/or tools that you’re proposing they use.
• They’re worried that the reasons for adopting the TOM aren’t well thought through.
• They’re worried that the plan for adopting the TOM has significant problems or flaws.
• They want to adopt the TOM, but they want to do it their way.
• They want you to fail so that they (or someone they like better) can get your job.
• They read this book.

Compounding the situation is the fact that you may face several of the reasons simultaneously, possibly from different sources.

Symptoms

Delays in getting approval or support. Rumors circulating behind your back. Objections constantly brought up in meetings. Former supporters distancing themselves from you. Reduction in project priority and resources.

Consequences

Significant project delays or project failure. Loss of influence. Loss of job.

Detection

If you suspect that resistance is deeper or more entrenched than you thought, you need to find out the sources of resistance and the reasons behind it. This can be hard, because the people resisting you may not be honest about what they’re doing, or why they’re doing it.

Furthermore, if the resistance is coming from above, your boss(es) may feel no obligation to explain their reasons.

Extraction

You have four choices, not necessarily mutually exclusive, based on the nature, depth, and source of the resistance:

• Push ahead in spite of it.
• Mollify or enlist those who resist.
• Redirect the project to quell the objections.
• Abandon the project gracefully and (maybe) try again later.

Prevention

Make a list of everyone who might have any input or influence and judge where they stand. If possible, meet with each one privately to sound out her or him—but recognize that you may not get an honest answer. Offer each person a chance to make criticisms and recommendations; let everyone feel a part of the project and the process. Build enthusiasm, pointing out specific benefits, particularly those of interest to each individual. Use each source to cross-check others. This process is known as “getting your ducks in a row,” and you’d better do that before you start. This process may be more critical for those below you than those above you; don’t underestimate the power of developers to make your life wonderful or miserable.

Having done that, assess the costs and risks in pushing this project forward compared to the possible benefits and rewards. Factor that with the probability of success and make your call. If it looks too dangerous, scale back or redirect. If it looks impossible, find somewhere else to work.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

…the computer-operated baggage system has crashed and luggage is now being sorted manually before being loaded on to planes.

Twelve return flights to short-haul destinations have been cancelled. . . .

In just over a week the £4.3 billion investment has seen an unimaginable series of PR catastrophes.

Around 19,000 lost bags had to be transported to Milan to be sorted, hundreds of flights have been cancelled, and thousands of furious passengers have sworn they will never fly BA again.

A lack of staff parking and faulty IT systems started the rapid descent into terminal chaos which has seen BA suffer a 5% fall in business class passengers and left it with a £16 million bill.

This, of course, will remind those of us who track such things on this side of the Atlantic of the 10-year failed effort by United Airlines to automate the baggage system at Denver International Airport. One can only hope that our British cousins get their problems solved and solved a bit quicker. ..bruce..

Officials at HM Courts Service (HMCS) say they have turned around a failing £447m project to provide a national case management system for magistrates courts – a scheme that is 16 years late and will cost nearly three times more than expected.

HMCS change managers say they have been standardising business practices in courts and “not just delivering an IT system”, since they took direct control of the project in January 2007.

Officials have told Computer Weekly that independent Gateway reviews of the Libra project have progressed from a red warning light in 2006 to amber last March and last month to green.

Libra, which is in 83 courts, is due to be rolled out to all 370 magistrates courts in England and Wales by the end of December.

HM Courts Service has changed direction by attempting to shape new business processes around the specific needs of those who work in the courts, rather than imposing any central diktat.

Executives on the change management team say they are rolling out new IT and business practices based on what works best in the courts, and validating it in live operation.

Those last two paragraphs are the most intriguing, and they point out the critical nature of change management (from a process and organizational sense, not in the ‘source code control’ sense) in any large-scale IT project that will impact business processes. Be sure to read the entire article; it not only gives more details, it also has links to earlier articles about the same project.