Webster & Associates LLC

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

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

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

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

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

Categories: managerial

It is a sad truism that upper management typically asks just two questions about a software development effort: “Why isn’t someone coding yet?” (known as the ‘WISCY’ question) and “When will the program ship?” These are not bad questions per se, but when they are the only questions asked, they have a tremendous distorting effect on the software development lifecycle. Software development involves so much more than just coding and shipping, so many other tasks that need to be done and done well. When those who hold purse strings for projects and power over careers focus on just these two aspects, then all the rest suffer.

This is doubly true when modern software engineering technologies and methodologies (”TOMs”) are involved, and trebly true when such TOMs being adopted by the organization for the first time. Success in such efforts depends upon thoughtful work in analysis and design, as well as an investment in quality throughout the entire lifecycle. It also depends upon have at least a core of talented developers with significant TOM-related skills and experience. And since most benefits of a new TOM come after the first few projects, these projects need to be done well.

Symptoms

Upper management focusing on just those two questions, especially in the early stages of a project.

Consequences

Coding starts much sooner than it should and for the wrong reasons. Early prototypes and experiments become the foundation of the final product. Projects drag on without stabilizing due to lack of architecture, good design, and quality engineering.

Detection

The simplest, most direct method is to work your way up the management chain, asking each manager, “What are your questions and expectations with regards to the project?” Listen carefully to the answers that you get, and don’t hesitate to ask follow-up questions.

Extraction

This is a painful one, because you have to educate upper management about the realities of software development while in the midst of a project about which they likely have unrealistic expectations (due to the TOM, particularly if it is the first time the TOM has been used). It is even more painful when you have been going along with the coding-and-ship focus, because you have to explain why you didn’t bring up all these other activities before. But that’s what you have to do: educate and explain. Almost any other course will lead ultimately to a larger disaster, though I must confess that there are project managers, directors, and VPs out there who are amazingly good at bringing crippled projects to apparent completion, then foisting them off onto others before they blow up or bog down. No one said life is fair.

Prevention

As with most pitfalls, prevention is easier-and less embarrassing-than extraction, but it can still be tough. In far too many organizations, upper management doesn’t want to know or refuses to believe the realities of software development. Still, you need to make the effort. Be honest in your project plan, set of tasks, and overall estimate. Beyond that, leave yourself some wiggle room. They may not accept it and indeed may mandate an unrealistic schedule and budget, but you will at least have gone on record with an honest estimate.

References

[Professional experience]

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

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]

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

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

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

CATEGORIES: political

You know the drill. By hook or crook, through long weeks and late hours and ruthless compromising, you finally deliver the project. It’s finished, it’s out the door, and you have taken a few weeks to remind yourself what real life is like. Now you have the opportunity to go back and make right all the hacks and shortcuts and ugly patches you used to get version 1.0 of the project to the customers. Besides, having done the project once, you now have a far better idea of how it should have been done in the first place. You rub your hands together and…

…you are handed a list of new features required by customers or potential customers for version 2.0 of the project, which has to ship far sooner than you would have thought. After some study, you realize that you’re not going to be able to deliver all those features within the required time frame — and even as you realize that, more features get handed down.

Your plans for cleaning up the code and the architecture are rapidly getting pushed off to version 3.0, and you really wonder whether things will be any different then.

Chances are, they won’t.

Why does this happen so often? There are several reasons, really. One may be economic necessity. Your company (division, group) may have to fund itself, which means that sales have to be sufficient to meet all expenses, including your salary and benefits. If that’s your situation, then don’t worry as much about this pitfall; architectural purity is nice, but a paycheck is better.

Another, less acceptable reason may be a short-term focus on the part of upper management. Determined to milk a current market opportunity and concerned primarily about next quarter’s results, they may not be receptive to an engineering investment that would yield more in the long run at the expense of smaller profits right now.

A third reason — not necessarily exclusive of the other two, and sometimes justified — is a suspicion on the part of upper management that engineers are more interested in doing something “cool” or “elegant” than in doing something profitable. What upper management may not understand is that elegance — architecture and code that are concise, yet clear and comprehensive, tending toward orthogonality — always pays off. Always. The only question is how soon and how much, and that is the fulcrum for the balancing act of the technical manager. Ironically, when the engineering staff is able to rapidly deliver the features requested by upper management, it is often because of a previous investment in elegance; likewise, when features take a long time to implement or bugs take a long time to fix, it’s often because of architectural gaps and past short-cuts.

Symptoms

Constantly having to push engineering work into the next planned release and not the current one.

Consequences

The cost of adding new features or extending current ones goes up, not down, over time. The program gets larger, less stable, and less cohesive. Bugs multiply, possibly causing a customer backlash.

Detection

Sit down with upper management and detail the engineering work that needs to be done. Indicate what impact this will have on the current list of desired features. See what kind of reaction you get.

Extraction

It ain’t easy. The reaction you get under Detection should give you a pretty good idea of what things will be like. There are two approaches, which should probably be used together. First, actively work with upper management and customers to determine which features are absolutely necessary and which are merely desirable — ones they could live without until the next feature release. It’s critical to talk directly with the customers, because they may not have done their own prioritizing; the list you get from management may reflect everything from essential requirements to blue-sky wishes.

Second, build engineering cleanup time into each feature so that an engineer allocated four weeks for a given feature spends, say, three weeks on the feature and one week on architecture.

Prevention

Besides using the steps described above in Extraction, you need to emphasize the need to make the proper ongoing engineering investment in order to gain the desired benefits, particularly if a new technology or methodology is involved. This means investing the time to educate management and customers, to set proper expectations, and (if possible) to run a trial project to demonstrate the process.

Contributor/References

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

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

CATEGORIES: political, architectural, managerial

While discussing the challenges of software development with Taligent trainer Tom Affinito back in the mid-1990s, I mentioned — citing Fred Brooks — the need for a chief architect. Tom immediately responded, “Yes, and ultimately architecture is a political act.”

That observation has stuck with me ever since. Unless you are both sole architect and sole implementor — and maybe even then — architecture is a political act, and it is especially true in development groups of any size. Developers like to think themselves above politics. Not so; they are as human as anyone else. Developers can be quite political and will use a variety of techniques, good and bad, to achieve their ends: persuasion, hyperbole, fear-mongering, caucusing, lobbying, consensus building, rumors, backbiting, leadership, intimidation, sacrifice, tantrums, threats, and subversion, to name a few. The fact that developers are generally very bright just increases the effectiveness of whatever techniques they use.

Architecture is the lodestar of developer politics because it is ultimately the most prestigious role in software development. Brooks goes to great lengths (and rightfully so) to assert the intellectual and creative challenges of implementation, noting that architecture is not the be-all and end-all. Still, it is Frank Lloyd Wright’s name that remains attached to the structures he designed, not the name of the contractors who built them. Or, to update an old programming joke, the verb “to develop” is conjugated this way: “I architect, you implement, he tests.”

Yet we may fail to recognize or acknowledge this situation and its implications. Why? First, we want to believe that all developers have (with regard to the project) the same intentions and goals. Second, we want to believe that the best course is the one that is obvious to us and that everyone else will agree with that. Third, we don’t want to have to deal with politics ourselves, particularly politics that can lead to confrontations.

Symptoms

Assuming — without verification — that all other members of the development group have the same goals, ideas, and talents. Not wanting to assert architectural issues. Finger-pointing as design problems arise.

Consequences

Hidden or overt team dissension, leading to poor morale and lack of cooperation as well as a weakened architecture.

Detection

Ask yourself these questions:

• Who is the chief architect of this project?
• How well do the other developers support the chief architect?
• How effective is the chief architect in her role?
• What are the obstacles she faces?
• What are all the political issues involved?

Answering these questions should go a long way toward determining whether you have underestimated the politics of architecture.

Extraction

The first issue to address is that of authority commensurate with responsibility: if there is a chief architect on the team, does she really have the authority to compel adherence to the architecture? This kind of authority is different than being able to say, “Do this or you’re off the project,” which often leads to subtle or overt rebellion by team members. This kind of authority accrues from several factors:

• a proven track record
• respect from teammates
• support from technical and upper management
• a mutual pact with the developers that the chief architect will give serious consideration to all their ideas and suggestions but that they will abide by her decisions
• a willingness to give in on the small things so that she can hold her ground on the big things

Beyond that, healing a team that is experiencing jealousy and dissension is no easy feat, especially when you’re in the middle of a project. Books and seminars on team-building abound; study, learn, and apply.

Prevention

Go through the questions in Detection but cast them in the future tense. Then, as with Extraction, proactively work to build the team and establish the authority of the chief architect.

Contributor/References

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

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

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

The opening of Terminal 5 at London Heathrow Airport has not been without problems, to say the least. And one of the specific problems appears to be the automated baggage handling system:

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

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

CATEGORIES: political

It’s easy to get excited about a particular technology or methodology (the “TOM”). And 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.

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