Top 10 classic development mistakes

Steve McConnell is a former Microsoft product developer who leverages research from many institutions in his books, blogs, and articles. Steve's focus on the "peopleware" and on motivation and high productivity provides one answer to "how to do more with less." The surveys on Classic Software Development Mistakes first appeared in Rapid Development in 1996 and were updated in 2007 with several new classics.

McConnell finds that some ineffective development practices have been chosen so often, by so many people, with such predictable, unsatisfactory results that they deserve to be called “classic mistakes”. Managers, developers and customers usually have good reasons for making the decisions they do, and the seductive appeal of the classic mistakes is part of the reason these mistakes have been made so often. Once you understand their effect on development speed, the list might help you avoid them.

1. Unrealistic expectations
One of the most common causes of friction between developers and their customers or managers is unrealistic expectations. Often customers simply start with unrealistic expectations since they are unaware of how much can be done in a project day. Sometimes project managers or developers inadvertently invite trouble by getting project approval based on optimistic estimates that don't take into account the reality of the "cone of uncertainty" caused by unknown requirements.

2. Overly optimistic schedules
The challenges faced by someone building a three-month application are quite different than the challenges faced by someone building a one-year application. Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on development staff, which usually hurts developer morale and productivity.

3. Shortchanged quality assurance
Projects that are in a hurry, due to the risk of missing the deadline, often cut corners by eliminating design and code reviews, eliminating test planning, and performing only perfunctory testing. This often results in the project reaching its feature-complete milestone but then still being too buggy to release. Shortcutting 1 day of QA activity early in the project is likely to cost you from 3 to 10 days of activity downstream (Jones 1994).

4. Wishful thinking
Wishful thinking isn’t just optimism. It’s closing our eyes and hoping something works when we have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to big blow-ups at the end of a project. It undermines meaningful planning and can be at the root of other problems.

5. Confusing estimates with targets
Some organizations set schedules based purely on the desirability of business targets without also creating analytically-derived cost or schedule estimates. While target setting is not bad in and of itself, some organizations actually refer to the target as the “estimate”, which lends it an unwarranted and misleading authenticity as a foundation for creating plans, schedules and commitments.

6. Excessive multi-tasking
When software developers are assigned to more than one project, they must “task switch" as they change their focus from one project to another. They must get out of “flow” on one project and into “flow” on another. Task switching can be a significant factor—some studies have said that each task switch in software development can incur a 5-30 minute downtime as a developer works out of flow on one project and works into flow on the other.

7. Feature creep
The average project experiences about a 25 percent change in requirements over its lifetime. Such a change produces at least a 25 percent addition to the software effort and schedule, which is often unaccounted for in the project’s plans and unacknowledged in the project’s status reports.

8. Noisy, crowded offices
About 60% of developers report that their work environments are neither sufficiently quiet nor sufficiently private. For many developers, this can prevent concentration and prevent achieving a state of “flow” that is helpful in achieving high levels of productivity. Workers who occupy quiet, private offices tend to perform significantly better than workers who occupy noisy, crowded work bays or cubicles.

9. Abandoning planning under pressure
Project managers make plans and then routinely abandon them when they run into schedule trouble. This would not be a challenge if the plans were updated to account for the schedule difficulties. The challenge arises when the plans are abandoned with no substitute, which tends to make the project slide into code-and-fix mode.

10. Insufficient risk management
Some mistakes have been made often enough to be considered classic mistakes. Other potential problems need to be identified project-by-project through risk management. The most common challenge with risk management is lack of awareness about the importance of it, hence, not having a plan to mitigate risks if they arise. The second most common problem with risk management is not doing enough risk management, usually due to inexperience.

"A blanket attempt to avoid mistakes is the biggest mistake of all." -- Steve McConnell

--From Rapid Development by Steven McConnell, Microsoft Press, White Paper

 

Baltimore Office
Local Phone: 410.583.9393
sales@softwareconsortium.com