Here’s my abstract of the talk:

INSIDE-OUT: Organizations too often treat software reliability as an ‘after the fact’ consideration, performing testing as a last step and then constraining it due to schedule and financial pressures. Webster will present a simple “inside-out” software lifecycle model where all software development activing (not just coding) takes place within a framework covering a broad spectrum of quality-related activities.

I’ll post the presentation slides (PPT, 340KB) here after the talk. ..bruce w..

Categories: managerial

This is a classic pitfall in software engineering. Typically, insufficient time is allocated for the problem specification, research, design, architecture, and review that should occur before coding and during each development cycle. Likewise, software quality assurance (SQA) is often given little time, money, or people. The whole focus is on coding, and often that is underestimated by assuming that development will be linear and that nothing will go wrong.

Adopting a new technology or methodology (the “TOM”) tends to compound this effect in several ways, some of which are discussed elsewhere. First, unrealistic expectations can creep in. Second, rapid prototyping and feature development can cause a false sense of progress. Third, coding time may well be genuinely reduced by the TOM.

As a result, an expectation can arise that all aspects of the development cycle, not just the coding portion, will be compressed. The first few times you use the TOM, it may require more time up front for design and architecture, and it’s likely to require as much or more testing time. As your development group gains more experience and expertise in the TOM, the entire cycle may start to compress, but that comes with time.

Symptoms

Non-coding tasks taking longer than the time allotted to them. Slowdowns during development due to a need to rethink design. Alpha and beta testing taking much longer than planned.

Consequences

Slipped schedules and missed deadlines. Rude surprises as design must be repeated or testing takes much longer than expected.

Detection

Apply Brooks’ rule of thumb: the time required for a project should break down into one-third for design and prototyping, one-sixth for implementing, and half for testing. If your proportions are radically different, then you may have misjudged the relative costs or at least, mislabeled them; a lot of design and testing gets buried inside implementation.

If you’re far along in your project, keep a close eye on time required for SQA and particularly for testing, which is usually underestimated. Agile methodologies do a better job of addressing testing up front, but SQA remains the poor cousin for most software projects.

Extraction

First, throw out your current schedule and do a hard reset of expectations, particularly among upper management. This is not easy to do, but honesty is always the best policy. Good luck.

Second, set up a development cycle—specify, design, prototype, review, implement, test—with the time allocated to each step in the cycle based roughly on the proportions given above. Recognize that the actual time for each step in each cycle will vary: An early cycle will tend to have more specification and design and less testing; a later cycle will reverse those proportions.

Third, manage through one complete cycle and see how well your estimated costs match reality. Adjust and repeat.

Prevention

First, get some project management software. It doesn’t have to be fancy; it just has to automate the task of adding the estimated times for each task, noting critical paths, and calculating a final date. This is important; attempting to schedule anything except the smallest and simplest project in your head will lead to unpleasant surprises.

Second, use steps two and three under Extraction to set up your schedule and to estimate relative costs. If possible, try this first with a relatively small project and then work up to larger projects. The goal is to be able to estimate both relative and absolute costs within a certain margin of error (say, 10 percent) on a regular basis.

References

Brooks, Frederick P., Jr. The Mythical Man-Month. Reading, MA: Addison-Wesley, 1995.

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

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

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

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

Categories: political

There is an oft-cited dictum in technology development groups: “It is easier to ask forgiveness than permission.” It is often true and sometimes crucial to circumvent bureaucratic foot-dragging and politics. But it is not always the best course, and the danger of following it is commensurate with the technical, financial, and political risks involved. And all three risks abound when an organization is moving to a new technology or methodology (the “TOM”).

Nevertheless, it is not uncommon for a development group to make the switch to the TOM with only minimal involvement and education of upper management. Indeed, management may not care very much or may even be supportive—having read an article about the wonders of this particular TOM in a weekly business magazine.

And that is where the pitfall lies. For unless the project comes in within acceptable time and budget limits, upper management will suddenly be asking hard questions reflecting reasonable or unreasonable expectations, given what they know or were told.

Symptoms

Apparent lack of knowledge or overly positive expectations or both on the part of management about the TOM and its role in the relevant projects. Sudden distancing or self- protecting activities if problems crop up.

Consequences

Lack of support and possibly active hostility from upper management if problems arise or if their expectations aren’t met. Finding yourself twisting in the wind. Career damage, lack of promotion, demotion, loss of job.

Detection

Sit down with upper management and find out how much they understand about this particular TOM and how it’s being applied in the relevant project(s). Have them detail their expectations. Find out their level of enthusiasm or concern for the use of this TOM.

Extraction

There’s little to do except start the education and enrollment process much later than it should have been. It may be really tough, depending on how current expectations compare to reality, and the truth is, there’s no good reason for not having done this before things got started.

Prevention

From the pitfall itself, it’s obvious that there are two separate (if related) tasks: educating and enlisting. The first comprises letting management know exactly what adopting this TOM entails, which means that you had better know yourself, and you’d better know it well enough to explain it to nontechnical people. Work to contain your own enthusiasm for this TOM; remember that it is safer to underpromise and overdeliver.

Second, and this is probably tougher, you need to enlist key people: those who can affect your budget and resources, and those who can affect the scope and direction of your project. If you can, prove yourself with small projects to establish credibility and to give your sponsors a track record to point to (and take credit for).

Reference

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

Categories: conceptual, political

Native tribes in the South Pacific developed “cargo cults” during the middle part of the 20th century. Having observed planes (such as the venerable DC-3) landing on their islands and discharging goods from inside, these tribes created simacrula of the planes and worshipped them, sure that goods would magically arrive as a result.

Something similar happens with many projects that are used to pioneer a new technique or methodology (the “TOM”). Those in charge select the TOM, possibly with supporting tools and technologies, and the team pushes ahead. Having gone through the motions and used all the right tools, the team and its upper management may presume that what they’ve created is properly in line with the TOM and as such will incur all the benefits thereof.

Unfortunately, what often results bears little resemblance to best practices — or even somewhat OK practices — in professional TOM development. The painful reality is that they are in many cases worse off than if they had simply used existing techniques, methodologies and languages.

Symptoms

Serious problems in schedule, functionality, and quality. Failure to achieve expected benefits of object technology.

Consequences

Project instability and schedule slip, often ending in partial or complete project failure.

Detection

When you raise issues concerning what is being (or not being) created, you get responses of “But we’re using [methodology/notation/language/technology]!” When you probe for actual understanding of TOM development within the project, you quickly run into blank stares, defensive attitudes, and canned answers.

Extraction

This is a hard one to push through to completion. In most cases, what you have to do is bring in some technology and process mentor; in far too many cases, you have to throw out everything that has been done so far and start over.

Prevention

Ensure that the development team has people on it who really understand the technology or methodology and who have the skill and experience to apply it correctly and successfully.

References

[Professional experience]

CATEGORIES: political

Imagine the following scene. Your company’s executive staff gathers for a presentation on a new technology or methodology that will revolutionize information productivity. After a presentation citing the ongoing problems of information management, enterprise computing, and competitive response, you are presented with the solution that will boost the company’s bottom line and guarantee its future: structured development using the C programming language!

But wait! you say. Structured development has been around for a long time, as has C. Lots of folks use structured development and C with mixed results; indeed, many don’t use it well. Lots of companies have gone out of business while relying upon structured development and C. How are structured development and C going to guarantee our future?

Good question. And yet, structured development and its associated methodologies — not to mention the C programming language and its versions — are likely more mature, established, and well understood in real-world applications than are any of the later technologies or methodologies (”TOMs”) that you may want to adopt. For that matter, the number of competent, practicing engineers who are expert at structured development and/or C is likely greater than the number of competent, practicing engineers who are expert at the particular TOM in question. If a company can’t succeed using structured development and C, why does it think it can succeed using a given TOM?

You may think that I’m being reactionary or that I don’t understand all the benefits that more modern TOMs have over structured development and/or C. If so, you miss the point: It is not technique (using Jacques Ellul’s term) in and of itself that will benefit the company, but rather its intelligent and purposeful application by people who know what they’re doing and why. To think that adoption of a given TOM (or even a collections of TOMs) will suddenly make everything better is irrational to the point of superstition.

Symptoms

Unrealistic expectations on the part of upper management. Marketers overpromising delivery times and feature lists. Technical managers who see the TOM as a silver bullet. Developers neglecting solid software engineering practices, because the TOM “doesn’t require them”.

Consequences

At best, you go through a wrenching reeducation and attitude adjustment. At worst, you lose the bet — and the company.

Detection

Take the company’s current business plan, mission statement, and product plans, and eliminate all references to and consideration of the TOM(s) in question. Do these documents still make sense?

Extraction

Point out, repeatedly, that it doesn’t matter what technology you use if the products aren’t worthwhile and if the company can’t get a return on investment. Enumerate the factors required for success independent of the TOM(s) in question. Look at all that you can do to maximize those factors. Then — and only then — look at how the TOM(s) in question can aid and support those efforts.

Prevention

Bet the company on your people, not on some technology or methodology. Isn’t that what politics is all about?

Contributor/References

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

CATEGORIES: political

Let’s try to keep our perspective while standing knee-deep in the hoopla. As anyone truly experienced in a specific technology or methodology (”the TOM”) will tell you, that TOM is not going to end world hunger or bring about peace in our time. It won’t transform the country of your choice into the new economic superpower of the 21st century. It won’t end cancer, reduce the number of handgun deaths, or curb the rate of out-of-wedlock births. It won’t even affect dandruff.

Closer to home, the TOM in question doesn’t invalidate existing programming languages, methodologies, and tools. It won’t make good engineers or architects out of bad ones. It also won’t make good products out of bad ones; although it may allow you to develop a better program than you might have otherwise, you can develop awful software just as well using a given TOM as you can using your favorite scapegoat legacy TOM.

Adopting a given TOM probably won’t make a late project ship on time, though it may allow you to complete a project that never would have shipped otherwise. On the other hand, it may well make the project even later. A given TOM won’t necessarily have a major impact on the time and effort required for analysis, design, and testing — except, possibly, to increase it as your team and/or organization comes up to speed on it. The TOM in question may not even be the best solution to the problems you face. It might, in fact, make things worse, not better.

Symptoms

An almost blind faith in the virtues of the TOM in question and an equal blindness to its pitfalls and failings.

Consequences

Arguments with others; a lack of flexibility; blindness to the TOM’s weak spots.

Detection

Analyze reactions to each of the statements above. When people disagree, note any strong negative emotional response. Have those who disagree with a given statement explain it to a disinterested, yet knowledgeable third party and see whether they think the logic holds water.

Extraction

As with many pitfalls, study and experience will do much to cure this one. Beyond that, the Detection method above will help you to identify specific areas of excess enthusiasm and credulity.

Prevention

Read books, articles and papers that address the TOM, including those in the Bibliography. Find people who have completed meaningful projects using the TOM and ask them for their lessons learned. Have them read the opening paragraphs of this pitfall and respond to any items they disagree with.

Contributor/References

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

CATEGORIES: political

It’s easy to get excited about a particular technology or methodology (the “TOM”). More often than not, they represent a real advance in software engineering, solving — or at least easing — problems that you face on a regular basis. And we all know just how tough software development can be.

However, enthusiasm for the TOM, particularly for individuals relatively new at it or with a vested interest in its adoption, may lead them to give glowing descriptions of its wonders and benefits to you and others. TOM proponents may make these comments in all sincerity and innocence. Or they may make them with the knowledge that they are stretching the truth a bit or perhaps rupturing it altogether. But whether they know that what they’re saying is accurate is, to a point, immaterial: when reality intrudes, the results will be the same, and their lack of knowledge or their lack of accuracy will convict them equally.

Symptoms

There are two phases. First, the people who have been oversold on a given TOM start to express expectations of the TOM that make you increasingly uncomfortable; you may find yourself starting to downplay things a bit. Second, as problems start to pile up, there are growing questions, doubts, and expressions of mistrust and cynicism.

Consequences

Those who trusted what they were told will feel betrayed; those who did not will feel justified. In either case, both the reputation and the influence of those doing the overselling will shrink, and it will be a long, hard road to recovery.

Detection

Sit down with a sheet of paper and write every promise, hope, and expectation that you or others have made in the name of the TOM in question. Ask yourself how supportable or valid each is. If you have questions about your ability to judge this, find someone who knows more about the TOM than you do and ask them for help evaluating how supportable or valid each point is. Ask yourself whether you’ve succumbed to wishful thinking.

Extraction

If you or others have oversold the TOM in question, you need to start readjusting expectations immediately. It is probably best to do it in one massive reset than to do it piecemeal — a single sword thrust is, in the end, less painful than a thousand paper cuts. As Fred Brooks says, “Take no small slips.” But it’s going to take a long time to reestablish your credibility, which is why it is so critical to avoid this pitfall in the first place.

Prevention

Several times in this book you will find the recommendation to underpromise and overdeliver. Believe it and make sure that others believe it. If you have questions about your ability to judge, then bring in two or three experts to consult and weigh their opinions.

On the other hand, if you knowingly oversell, telling yourself that you can manage things down the road, you will almost certainly be wrong. Resist that temptation. It will always get you into trouble, and your own integrity will be diminished. It’s just not worth it.

Contributor/References

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