Classic mistakes of software development

In my post How Much Do Websites Cost I wrote of those mistakes which I kept seeing clients make, over and over again. My list somewhat overlaps with the list of classic mistakes that Steve McConnell writes about:

People Mistakes

1. Undermined motivation
2. Weak personnel
3. Uncontrolled problem employees
4. Heroics
5. Adding people to a late project
6. Noisy, crowded offices
7. Friction between developers and customers
8. Unrealistic expectations
9. Lack of effective project sponsorship
10. Lack of stakeholder buy-in
11. Lack of user input
12. Politics placed over substance
13. Wishful thinking

Process Mistakes

14. Overly optimistic schedules
15. Insufficient risk management
16. Contractor failure
17. Insufficient planning
18. Abandonment of planning under pressure
19. Wasted time during the fuzzy front end
20. Shortchanged upstream activities
21. Inadequate design
22. Shortchanged quality assurance
23. Insufficient management controls
24. Premature or too frequent convergence
25. Omitting necessary tasks from estimates
26. Planning to catch up later
27. Code-like-hell programming

Product Mistakes

28. Requirements gold-plating
29. Feature creep
30. Developer gold-plating
31. Push me, pull me negotiation
32. Research-oriented development

Technology Mistakes

33. Silver-bullet syndrome
34. Overestimated savings from new tools or methods
35. Switching tools in the middle of a project
36. Lack of automated source control

He’s added some new ones:

* Confusing estimates with targets
*
Excessive multi-tasking
*
Assuming global development has a negligible impact on total effort
*
Unclear project vision
*
Trusting the map more than the terrain
*
Outsourcing to reduce cost
*
Letting a team go dark (replaces the previous “lack of management controls”)

Of these, the ones that I’ve seen my clients make would include:

Unclear project vision

Outsourcing to reduce cost

Feature creep

Lack of effective project sponsorship

Unrealistic expectations

Insufficient management controls

Overly optimistic schedules

These tend to be related. I’ve mostly worked with inexperienced entrepreneurs whose inexperience leads them into a manic-depressive cycle of over-confidence followed by extreme self-doubt, followed again by over-confidence. The lack of confidence leads to feature creep, which grows out of a desire to be all things to all people. This reflects an “unclear vision for the project”, which leads to a “lack of effective project sponsorship”. The lack of experience also leads to “unrealistic expectations” which feed into “overly optimistic schedules”. But all of these are really just parts of the larger problem of wishful thinking, which McConnell describes at length:

I am amazed at how many problems in software development boil down to wishful thinking. How many times have you heard statements like these:

“None of the team members really believed that they could complete the project according to the schedule they were given, but they thought that maybe if everyone worked hard, and nothing went wrong, and they got a few lucky breaks, they just might be able to pull it off.”

“Our team hasn’t done very much work to coordinate the interfaces among the different parts of the product, but we’ve all been in good communication about other things, and the interfaces are relatively simple, so it’ll probably take only a day or two to shake out the bugs.”

“We know that we went with the low-ball contractor on the database subsystem and it was hard to see how they were going to complete the work with the staffing levels they specified in their proposal. They didn’t have as much experience as some of the other contractors, but maybe they can make up in energy what they lack in experience. They’ll probably deliver on time.”

“We don’t need to show the final round of changes to the prototype to the customer. I’m sure we know what they want by now.”

“The team is saying that it will take an extraordinary effort to meet the deadline, and they missed their first milestone by a few days, but I think they can bring this one in on time.”

Wishful thinking isn’t just optimism. It’s closing your eyes and hoping something works when you have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to big blowups at the end of a project. It undermines meaningful planning and may be at the root of more software problems than all other causes combined.

Leave a Reply