Cleaning up some old files today, I noticed some old notes I'd written on Classic Software Development Mistakes. Rather than throw them out, I thought I'd share them here.

Adding manpower to a late software project makes it later

-- Brooks' Law

This is probably the most common mistake I've seen over the years. Throwing more people at late projects seems like a reflex reaction for most managers. While Brooks reaffirmed his law in his Mythical Man-Month Anniversary Edition twenty years after he first proposed it, Steve McConnell has argued, unconvincingly in my view, that Brooks' Law no longer applies:

The time that existing staff spends with new staff certainly does take productive time away from the project, and time spent training can be frustrating to existing staff members who are already feeling pressured to complete their own work. But the loss is nothing like the ratio needed for Brooks’ Law to be true.

-- Steve McConnell

While McConnell's argument sounds logical, the crucial point here is how capable and well-trained are the new staff thrown at the troubled, late project? If they are capable and familiar with the domain, fair enough. Yet in my experience, capable staff tend to already be extremely busy. Moreover, their bosses are unlikely to release them. That only leaves B-grade performers (whose bosses may be only too happy to let go for a few months) and new hires. Now, throwing untrained and mediocre developers at a troubled project has a devastating effect on morale. Existing project staff, already under extreme pressure, now find themselves spending inordinate amounts of time training and spoon-feeding their new group of hairdressers and telephone sanitizers ... which typically leads to the better project team members resigning, the less capable ones being unable to secure a new job. Only the dead wood left behind. That is a terrible long term strategy for any company.

Sadly, I'm yet to meet a high level manager who has actually read The Mythical Man-Month. Or who knew what Brooks' Law is.

Of course, blaming it all on Brooks' Law is an oversimplification. Often the project is not really "late" at all, but a victim of overly optimistic scheduling and poor estimation. Poor hiring and training can also cause a project to take longer than it would were a stronger team available.

I'm not the sort of engineer that Google usually looks for. You see, I don't have a computer science degree from an elite university, or indeed any degree at all. I don't have any pretensions toward being a computer scientist, though I'm familiar with enough of the concepts and terminology to be able to work with them. I'm more the type to know and use tools -- preferably popular free and open source tools -- that other people have built, but of course Google's not very interested in that. I've also spent a lot of my time in the tech field on teaching, mentoring, encouraging software teams to adopt best practices, building relationships with other teams and with users of our software, advocating openness and transparency, and so forth, none of which Google's hiring practices care about or look for. It's all algorithm pop-quiz, and I'm crap at those.

-- Skud Blog, A note to Google recruiters

As illustrated by the above blog, Google's infamous hiring practices are often criticized for being ridiculously onerous with an over emphasis on excelling at algorithm pop-quizzes. Certainly, Google set the hiring bar very high and must surely reject many candidates who would have turned out to be model employees if given the opportunity. Yet I agree with their overall hiring philosophy: that it is far better to reject good candidates than to hire poor ones.

A common hiring mistake I've seen over the years is for a non-technical manager to hire developers without asking developers to be involved in the hiring process and without asking candidates to write any code. If you do that, it's very easy to hire developers who can hardly code at all. These sort of hiring mistakes are incredibly expensive and demoralizing because working with mediocre programmers usually frustrates the stronger developers, sometimes to the point of resignation, while sacking new hires can be a very unpleasant and traumatic experience for all concerned. Not to mention the cost (time, money and opportunity) of needing to re-hire.

Most product managers that I have worked with would rather ship a failure on time than risk going late.

-- Alan Cooper in The Inmates are Running the Asylum

Knowing the "right" product to build is hard, very hard. Who would have thought that twitter would be such a success? Well, it sounded like a daft idea to me. Actually, it still does. :) So product managers are an easy target. The two most common product mistakes I've seen are shipping a failure on time (as indicated by the above Cooper quote) and building the wrong product. Another more subtle strategic mistake is trying to build too many products thus spreading your resources so thinly that none of them are any good.

A classic example of building the wrong product, mentioned in Patrick Copeland's innovation at Google talk, was Bill Gates' unshakable belief that users wanted to see a Windows "Start" button on their mobile device. As you might expect, most Microsoft employees were reluctant to challenge the company founder on what product to build. Maybe pretotyping would have helped here.

I could rabbit on and on, but that's enough from me. I'd love to hear about the software mistakes you've seen. To help jog your memory, I list below a summary from McConnell's Classic Mistakes Enumerated.

People-related 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-related mistakes

1. Overly optimistic schedules.
2. Insufficient risk management.
3. Contractor failure.
4. Insufficient planning.
5. Abandonment of planning under pressure.
6. Wasted time during the fuzzy front end.
7. Shortchanged upstream activities.
8. Inadequate design.
9. Shortchanged quality assurance.
10. Insufficient management controls.
11. Premature or too frequent convergence.
12. Omitting necessary tasks from estimates.
13. Planning to catch up later.
14. Code-like-hell programming.

Product-related mistakes

1. Requirements gold-plating.
2. Feature creep.
3. Developer gold-plating.
4. Push me, pull me negotiation.
5. Research-oriented development.

Technology-related mistakes

1. Silver bullet syndrome.
2. Overestimated savings from new tools or methods.
3. Switching tools in the middle of a project.
4. Lack of automated source-code control.

Perl Monks References

• Dumb Mistakes (2001)
• Greatest programming mistakes and what to learn from (2004)
• Stupid mistakes I repeatedly make (2005)
• Little annoying mistakes ... of others (2008)
• Don't slides by tinita
• On Interviewing and Interview Questions
• Re^2: On Interviewing and Interview Questions (Beware of a guy in a room)

References

• Classic Mistakes Enumerated by Steve McConnell
• A Case Study in Classic Mistakes by Steve McConnell
• Construx Classic Mistakes 2008 (Blog/Survey)
• Construx Classic Mistakes 2008 (Results/pdf)
• Things you should never do (rewriting) by Joel Spolsky
• Joel Discussion of Classic Software Mistakes (closed)
• How to write unmaintainable code by Roedy Green
• Classic Testing Mistakes by Brian Marick
• The Mythical Man-Month
• Brooks' Law
• Brooks' Law Repealed? by Steve McConnell
• Brooks' Law and Open Source: The more the merrier?
• Brooks' versus Linus' law: an empirical test of open source projects