My library of books should have a wing dedicated to Steve McConnell. He’s a great writer, in that he discusses technical issues with an approachable style and a practical outlook. Much like Peopleware, he’s looking for things that can be proven to work, not just treading out the same axiomatic fluff that eventually becomes mantra because it’s repeated so many times. To give you an idea of the impact his books and articles have had, in 1998, he was named alongside Bill Gates & Linus Torvalds as the one of the 3 most important people in the software industry by Software Development Magazine.
Today we’re going to focus on Rapid Development, mainly because it ties in so well with my previous blog on Peopleware. Rapid Development is all about how to manage a program or a project. It was written after his book Code Complete, which you can expect to see showing up in this blog shortly. Code Complete focuses on the day-to-day practice of how to code and techniques to employ, while this book focuses more on the software engineering aspect, looking at methodologies and practices that work and don’t work, and why.
Early on in the book, McConnell hits you with some of the “Classic Mistakes”, and this is sure to make you wince if you’re fairly experienced. One of those winces for me was the “Overly Optimistic Schedule” (see my blog on this mistake). Some of them won’t evoke such bad feelings, though…you might even get a little boost from memory of how you successfully navigated one of them. For me, that one was the classic mistake of uncontrolled problem employees. I don’t know that I actually solved the problem myself, but I don’t wince because everything turned out great. You can read about it HERE.
As an aside on hiring, I’ll point out that many people don’t realize that a bad hire doesn’t just “not help”…it actually hurts. The wrong employee doesn’t just contribute at a rate lower than others, they can actually have a negative overall contribution to the team. Think about all of the time invested in a person training them up, having weekly meetings with them, and how much time their mistakes take other people time to fix. And then figure up all of the motivation and momentum that the “wrong” person can suck out of a team. Someone that is incompetent or negative can completely sidetrack a team as they devote energy to dealing with them. Too often, though, the belief is to just “fill the spot” with a candidate that’s less than stellar. This lack of recognition of the value of each and every team member on a software team often shows the need for management to clue in and read one of the other “Must Read” books, Peopleware.
Other classic mistakes that I’ll point out is the “overestimation of savings from new tools and technologies”, which goes hand-in-hand with the “Silver Bullet Syndrome.” Both are related to human nature in that we always try to look for just one thing that will be the huge productivity boost the manager desires. It’s not sexy to realize that you’re not going to get a 30% productivity gain from the application of one thing, like the latest version of Visual Studio, or moving everyone to the cool new language/library, or implementing Agile (especially given how many “Agile shops” are anything but Agile!), etc. Large productivity gains are the combination of doing 1000 small things correctly, and then implementing the right changes that continue to build upon the base you already have. But again, it’s human nature to always expect a little more, so not only does Steve McConnell cover this, but Dr. Fred Brooks (author of The Mythical Man Month) also wrote up a short treatise about it. You can find “No Silver Bullet” easily with an internet search, and it has also been reprinted in later copies of The Mythical Man Month. I’ll cover it in a blog here in the near future, as understanding accidental versus essential complexity is a key skill as a software designer.
And to build on this idea of how 1000 small things must be done well for great productivity gains, McConnell devotes the last section of the book to be an encyclopedia of software best practices. Well, it’s actually better than an encyclopedia because it breaks down and correlates each of the best practices to specific problems that it solves and trade-offs or issues that it might cause itself. It’s not that you need to go and do every single one of these gains, it’s that you need to be aware of what you’re gaining from choosing a particular best practice, and what you might be losing or conflict you might be creating as well. And the key to remember is that this isn’t written for the programmers specifically. We’ve got enough books on “how to get better programming”, such as McConnell’s own Code Complete, the Gang of 4’s Design Patterns & Refactoring books, etc. This is written for management and senior development to determine the best way to plan for development. This is a software engineering book, which is why I said up front that it goes hand-in-hand with a book like Peopleware. You’ll even see some overlap, such as both recommending taking advantage of The Hawthorne Effect. Highly recommended.