|Problems? Is your data what you think it is?|
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.
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:
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.
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.
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.
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.
Perl Monks References