Each technology is on its own product lifecycle, which may or may not match with your organization’s business and development lifecycles. In particular, there are certain cycle mismatch patterns that commonly occur in organizations looking to adopt new technologies. I’ve labeled four such mismatch patterns: firefly, underdone, conveyer belt, and landfill. Each is worth examining.

Go read the whole thing.  ..bruce..

The second column, “Do Not Defer The Difficult in IT Projects”, describes the all-too-human tendency in IT development to put off dealing with the toughest problems until last — at which point, you may not be able to solve them all. It also explains why so many IT projects get 80-90% “done” and then suddenly slip for weeks or months without making much progress.

Feedback is always welcome.

The other day, an IT colleague of mine mentioned a conflict at a corporation where he’s working. The corporation has a mission-critical application deployed across a large number of workstations. The set of corporate employees who use this application largely use it and nothing else all day long at dedicated workstations. The application they are using is a customized third-party application; however, the firm has been having chronic problems with this app (let’s call it “QRSApp”), and so is looking at different solutions. The firm could continue to make changes to QRSApp to fix their problems. The firm could switch to a different third-party application; several other vendors market applications of this type within this firm’s industry. Or, as a senior IT manager now wants to do, the firm could develop a completely custom and private application to replace QRSApp, so that the firm has complete control over it.

The question: which solution is best?

Comments welcome here or there.  ..bruce..

But sometimes with projects that really shouldn’t succeed—that are attempting too much, too fast, with too many risks—enough things go right, particularly along the critical paths, enough superhuman effort is made by those involved, so that the project does indeed go into production on time and possibly even under budget. Upper management is thrilled; the development team looks great; and all’s right in heaven.

And that’s when the real trouble begins.

Feedback is welcome, there or here.  ..bruce..

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: managerial

Why would the use of a new technology or methodology (the “TOM”) cause managers and developers to neglect or even abandon solid software engineering practices? Because those practices are under pressure from the start. Many engineers don’t know them and aren’t willing to spend (or aren’t given) the time to learn them. Those who do know them often aren’t willing to spend (or aren’t given) the time to practice them. Technical managers, who often do understand such techniques, find themselves caught in a vise, trapped between ever-increasing (and possibly unrealistic) demands of upper management and the productivity level of the engineers they supervise.

The introduction of a new TOM can cause a new set of problems. Upper management, having read articles about the benefits of this particular TOM, may see it as an opportunity to increase demands. Developers, already under pressure to produce, milk the benefits of the TOM for all they’re worth and may find even less incentive to focus on solid software engineering. And the technical managers in the middle have to cope with the specifics of the TOM while still fighting the software engineering battles.

Symptoms

Upper management expects the TOM to immediately shorten the software development lifecycle and is unwilling to allocate the necessary time and resources pilot projects. Engineers neglect common sense and best practices, feeling instead that the TOM somehow magically supersedes both. Unrealistic expectations from upper management puts pressure on the development team, resulting in even more shortcuts.

Consequences

Failure to achieve expected benefits of the TOM, possibly leading to (unwarranted) rejection of the TOM for future projects. Delayed, buggy, and/or failed projects.

Detection

It’s usually not hard to detect the pressure from upper management; indeed, the problem is resisting the pressure. As for the engineering-level problems, the best detection comes from regular team meetings and project reviews to go over standard (TOM-independent) software engineering practices.

Extraction

This pitfall is a hard one to get out of, because upper management needs to allocate more time and resources, and the engineers need the self-discipline and education to change how they’re doing things. The key is to educate everyone about the benefits of good software engineering — established practices, predictable schedules, and higher quality — and then work the TOM into that setting.

Prevention

It is sad that there is often so much resistance to doing things right in the first place. The approach is direct: realistic scheduling, definition of engineering standards, and enforcement of engineering practices. For starters, make everyone — especially upper managemen t– reads The Mythical Man-Month by Frederick P. Brooks. Then refer to it again and again as these problems arise.

References

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

Categories: political

Face it: technology adoption is a gamble, and one often made at gunpoint. External market forces lead internal political forces to demand advances — often unrealistic ones — in information technology. Those who adopt too soon come to understand the cliché “bleeding edge”. Those who adopt too late lose opportunities and possibly market share. And so you find yourself looking a dozen new technologies and trying to decide which to adopt, knowing that only two or three are likely to succeed: that is, deliver what you need and grow with your ever-increasing demands. A winner is always easier to pick in retrospect, but you seldom have that luxury. Instead, you need to decide between adopting a “safe” technology — which may not, in the end, really meet your needs — or leading out with a newer technology and thus run the risk of finding yourself in a dead end with a non-standard or even unsupported solution or approach.

But that’s why they pay you the big bucks, right?

Just as a personal note, I spent five years (1990-95) and $7 million in venture capital as part of a software start-up that developed and shipped a design-oriented desktop publishing system for . . . the NeXTstep operating system. As I tell people, it seemed like a good idea at the time. It was a great operating system (still is — go look at Mac OS X) and certainly better than anything else out in 1990. And we were in good company at the time, with firms such as WordPerfect, Ashton-Tate, and Adobe all developing for NeXTstep as well.

But it was the wrong horse.

Symptoms

Peers and managers above you start questioning your choice of technologies. The number of other organizations adopting the technology in question doesn’t seem to be growing much, or is even shrinking. Developers experienced with the technology are hard to find.

Consequences

Your system and/or development effort struggles due to the lack of developers and third-party tools for the technologies in question. If you’re developing a commercial product, you may find a very limited market, assuming you find one at all. If you’re developing an in-house system, you may end up deploying it, but the system may be difficult to maintain and keep in production for its original hoped-for lifetime. And if you were the champion for adopting that particular technology, you may find yourself losing influence, missing out on promotions, and possibly even out of a job.

Detection

Track down and talk frequently with other firms adopting the same technology. Fact-check, as best you can, claims by the technology’s vendor regarding adoption and market share. Pay particular attention to the products or systems based on this technology that are actually deployed into real-world use.

Extraction

If you think you’ve picked the wrong horse, then start to find the right one, quickly. Figure out what it’s going to take to move over to the better (or best) technology. Work up a careful transition plan — as accurate and conservative as you can make it — and then figure out what it’s going to take to sell this to upper management. There may be no good or easy paths at this point.

Note that there are cases where you may well be best off staying on the technology you originally picked, particularly if this is an in-house system. That is, it may be more cost effective to push into production, then plan for an earlier-than-expected end-of-life for that system, rather than try to switch horses in mid-race.

Prevention

This is hard precisely for the reasons stated above: in many cases, you just don’t know what will succeed and what won’t. If you’re talking about a major decision — such was what operating system to develop for and deploy on — your choices may be limited by other factors. In general, though, you want to avoid the leading/bleeding edges — never count on version 1.0 (or even 1.x) of anything. You want to choose technologies that have been out in the marketplace long enough to have the flaws exposed and — one hopes — the biggest problems addressed.

References

[Professional observation]

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).