in reply to Common Software Development Mistakes
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.I think the fallacy here is to assume that anyone working on the project needs to be an as top-notch programmer as you are. Usually, that's not the case. Many projects only need "expert" knowledge for a fraction of the project, but the rest is just "grunt" work. There's often the odd webpage, conversion script, monitor, cronjob wrapper, test suite, documentation, etc, that can be offloaded to a "lesser" programmer, freeing up "expert" time. If only all they do is fetch coffee, or read Perlmonks for you.
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.Has that actually worked for you on a structural bases? Is it worth the time it takes? (Cause not only does the developer-to-be write the code, you need people to judge it). How do you deal with the fact many candidates are under stress? Are you giving them new, non-trivial tasks, or do you give them (part of your) existing code base, and ask to modify it - the latter is for many companies a far more realistic scenario.
In Section
Meditations