Mashing Deadly Myths

Software Development
March 2004

Mashing Deadly Myths

Sometimes, those “inevitable” constraints plaguing your project aren’t so inevitable after all. These myth-mashers kick-start new ways to ensure your project’s success.

One of the most interesting aspects of the IT community is our ability to deceive ourselves. Studies such as the Chaos Report indicate our pitiful success rate—only 16 percent of projects are on time and under budget—yet we don’t see the need to change our ways. We’ll even fight to continue doing what we’ve always done because we’ve somehow convinced ourselves that it’s the best way of working, regardless of the evidence before us.

This month, I’ll explore the seven myths that I hear most often from IT professionals—and offer some advice on how to mash them. Sometimes they know they’re spouting a myth, sometimes they hope it’s the truth but suspect something isn’t quite right, and sometimes they’ve been so inundated with the traditional software development community’s rhetoric that they haven’t even thought to question it.

Seven Deadly Myths

1. Our project team maintains a “top 10 risk list.” We all know that it’s a good idea to identify and mitigate project risk; it’s just the actual execution of this concept that we seem to struggle with. I have no doubt that many teams maintain a risk list—but what’s on it? For example, on how many of your projects was your gravest risk either a senior IT manager or a key business representative? I note many hands raised—yet have you ever seen these folks listed as risks? Of course not. You’ll rarely see these individuals’ mistakes cited as a risk for fear that everyone will know that you think they’re not competent. Instead, you’ll see politically correct entries such as “Strategic misalignment of critical parties”—something that clearly sounds like a problem, but is vague enough that nobody really knows what it means. In reality, most “top 10 risk lists” are really just “top 10 palatable issues” lists.

Myth-Masher: Manage risk on your project, but in the process, jettison the overhead surrounding your list management process—having one less report and one less weekly meeting is always a win. At the same time, you need to discover how to educate the higher-ups—always a time-consuming process despite its great long-term payback—or convince them to trust the team to do a good job. The easiest solution? Find something “far more important” for the higher-ups to concentrate on.

2. This is the only way it can be done. I hear this refrain all the time, particularly from IT professionals who specialize in one slim aspect of development. For example, how many times have you heard something like “We can use only natural keys on these tables” or “An EJB application server is our only option here”? Perhaps surrogate keys or a .NET solution would be appropriate in the respective situations, but you’ll never know if you’re not allowed to consider them.

Myth-Masher:Personally, I’ve never been in a situation in which I didn’t have options, even though I’ve been told otherwise many times. More often than not, when people tell you “This is the only way,” it’s the only way that they know or it’s the way that best suits their political goals. To consider the strengths and weaknesses of various solutions, gain as broad a base of experience as possible, too. The more options you understand, the better you’ll be as a developer. Forcing yourself to think from another perspective can offer unexpected benefits.

3. We need this documentation. I’ve never understood it, but for some reason, bureaucrats mistakenly believe that documentation means something. Have you ever been on a project that had a fully documented, reviewed and accepted design, yet the developers ignored it and did their own thing? Have you ever supported someone who had access to user manuals but never bothered to crack them open? Have you ever been on a project that had a very detailed project plan, yet many of the people supposedly working to that plan had never even seen it? Even though the documentation exists, its target audience may be unwilling to use it, regardless of the effort put into its creation.

Myth-Masher: Most documentation is written for no other purpose than to soothe a bureaucrat. Whenever people insist on documentation, ask them why they want it, what they’re going to do with it, and who will actually use it. This will provide insight into what you actually need to write—sometimes, a 50-page document can be shrunk to 10. After you get that vital information, treat it like any other system requirement: Estimate how much it will cost to develop and maintain. Then have the requesters prioritize this and put it into the list along with the rest of the requirements. If you then implement the requirements in priority order, you’re always guaranteed to be working on the most important task at any given time, and every so often (though not that often), that will be creating documentation.

4. We need a team of specialists. This myth stems from early 1900s Taylorist theory, which recommends subdividing complex processes into simpler tasks that are then handled by people specifically focused on that one activity. This approach works well when you’re building thousands of copies of a uniform product, but for unique endeavors such as a software development, it often proves disastrous. Specialists frequently have difficulties interacting with different specialists, require more documentation that must then be reviewed and managed, and need far more people on the team.

Myth-Masher: What’s really necessary is a team of generalizing specialists—people who have one or more development specialties, as well as a general knowledge of software development and ideally even a general knowledge of the business domain. Because these people have a better knowledge of the overall process, they tend to understand the implications of their work, and don’t require as much documentation.

5. The information is lost if it’s only in the code. This statement is clearly false: How can it be lost if you know where it is? The information might be lost to them if the folks in question can’t read source code, but isn’t the real problem a lack of development skills? Organizations that subscribe to this myth will invest far too much in documentation, increasing their costs, while slowing themselves down.

Myth-Masher: Again, this solution calls for building teams of generalizing specialists, people with the confidence and ability to work with the wide range of artifacts created during development. If you focus on writing high-quality code and putting documentation in the single most appropriate place (which is often the code), people will start to see this as an incredibly effective way to work. All I’m suggesting is that you apply the fundamentals of data normalization, the desire to store information in one place only, to documentation.

6. We need a detailed process definition. Just as bureaucrats think that you’ll read documentation, they also assume that you’ll read and then follow defined software processes. The only time that I’ve ever seen anyone read a process definition is when they’ve never done the job before. Once they’re familiar with the task, they’ll never look at the process definition again. This is true of even the riskiest activities. For example, thousands of people die in car accidents every year, yet when was the last time you opened a driver’s manual? Unfortunately, many people seem to suffer from what I call the space shuttle antipattern: “If the process isn’t sufficient to build the space shuttle, it clearly isn’t good enough for building the management reporting system we need.”

Myth-Masher: In reality, your process definition efforts are usually for naught. You’re better off developing a high-level overview of how things should work, producing templates and examples of key artifacts, and then ensuring that everyone is given the training and mentoring they need to gain the skills they require.

7. We need to review this artifact. Too much faith is put in reviews and inspections, and when they’re done well in the right situations, they do produce results. However, reviews are compensatory practices—they compensate for communication barriers such as disparate locations, which result in inconsistencies between artifacts; little or no artifact sharing, which allows people to get on the wrong track without being caught for awhile (if ever); and overspecialization of skills, which results in narrowly focused decisions that ignore the bigger picture.

Myth-Masher: You can find more effective ways to gain the same benefits that reviews offer, such as colocating your team, collective ownership of artifacts and, once again, forming teams of generalizing specialists. When you do this, you quickly find that the value of reviews becomes negligible. You don’t need to hold a review; instead, address the issues that reviews address in a more effective, preemptive manner. Of course, I still haven’t found a way to gain the one benefit of reviews that I didn’t mention: earning that all-important little gold star.

Each of these myths might not seem so deadly on their own, but in concert, and over time, they start to add up, and their collective weight can drag down the most promising project. I’m sure your organization suffers from several, if not all of them, as well as a few that I’ve missed. If so, feel free to e-mail me ([email protected]) new myths and their associated mashers, so I can share them in future columns. The software development industry is at a critical time in its history, and we need to start questioning what we do and why, and seek out better ways to achieve our goals. It’s scary to move from myth to reality, but it’s a vital step to create a more efficient future for our industry.