14 July 2007

The Complete Code Book

by mo

Earlier this week I finished reading “Code Complete” by Steve McConnell. I have to admin that everyone who has ever recommended reading this book, was absolutely correct for doing so. It’s about 860 pages long, and it’s worth reading every word. What I found this book did for me was help me to reflect on my last 3 years of software development.

Early in my software construction career, a wise programmer handed me his copy of “Code Complete” and told me I might be interested in reading it. I thumbed through the pages but didn’t really give it a fair try. I just wasn’t interested in a book that talked about programming but showed very little source code. (At that time it was all about C programming for me). Man, I was a silly kid, if I had just listened to the wise programmer who handed me the book!

As I was read through the book, there were many times where I felt like “I remember being in a situation like that”, or “That’s so true, I never thought about it like that.” It was excellent and I recommend it to anyone who is currently involved in software construction.

** Code Complete, Second Edition ** by Steve McConnell Read more about this title…

Here’s a list of some of my favorite quotes from the book.

“Programmers like Global Gary, who litter their code with defects and “complete” their programs quickly, are rewarded more than programmers like High-Quality Henry, who write excellent programs and make sure that they are usable before releasing them.” “Testing’s goal runs counter to the goals of other development activities. The goal is to find errors. A successful test is one that breaks the software. The goal of every other development activity is to prevent errors and keep the software from breaking.” “Developers sometimes wonder whether it’s better to write test cases after the code has been written of beforehand (Beck 2003). The defect-cost increase graph suggests that writing test cases first will minimize the amount of time between when a defect is inserted into the code and when the defect is detected and removed. This turns out to be one of many reasons to write test cases first:” “… confirm another version of the General Principle of Software Quality: it’s cheaper to build high-quality software than it is to build and fix low-quality software.” “The term ‘scaffolding’ comes from building construction. Scaffolding is built so that workers can reach parts of a building they couldn’t reach otherwise. Software scaffolding is built for the sole purpose of making it easy to exercise code.” “Before you fix a problem, make sure you understand it to the core. Triangulate the defect both with cases that should reproduce the error and with cases that shouldn’t reproduce the error. Keep at it until you understand the problem well enough to predict its occurrence correctly every time.” “A class has poor cohesion: If you find a class that takes ownership for a hodgepodge of unrelated responsibilities, that class should be broken up into multiple classes, each of which has responsibility for a cohesive set of responsibilities.” “Requirements for the ‘design ahead’ code haven’t been fully developed, which means the programmer will likely guess wrong about those future requirements. The ‘code ahead’ work will ultimately be thrown away.” “Return as soon as you known the answer instead of assigning a return value within nested if-then-else statements: Code is often easiest to read and least error-prone if you exit a routine as soon as you know the return value. The alternative of setting a return value and then unwinding your way through a lot of logic can be harder to follow.” “One of my former roommates was a great procrastinator. He justified his laziness by saying that many of the things people feel rushed to do simply don’t need to be done. If he waited long enough, he claimed, the things that weren’t important would be procrastinated into oblivion and he wouldn’t waste his time doing them… Lazy evaluation is similar to just-in-time strategies that do the work closest to when it’s needed.” “Code that receives an award should be exceptionally good. If you give an award to a programmer everyone else knows does bad work, you look like Homer Simpson trying to run a nuclear reactor.” “If you implement each change as it occurs to you, you’ll soon find yourself walking on a software treadmill - for all that the system will be changing, it won’t be moving closer to completion.” “A significant percentage of the projects that are perceived to be late would actually be on time if they accounted for the impact of untracked but agreed-upon changes. Poor change control allows changes to accumulate off the books, which undermines status visibility, long-range predictability, project planning, risk management specifically, and project management generally.” “The implication for recruiting and hiring is clear. If you have to pay more to get a top-10-percent programmer rather than a bottom-10-percent programmer, jump at the chance. You’ll get an immediate payoff in the quality and productivity of the programmer you hire, and you’ll get a residual effect in the quality and productivity of the other programmers your organization is able to retain because good programmers tend to cluster.” “If you construct and integrate software in the wrong order, it’s harder to code, harder to test, and harder to debug. If none of it will work until all of it works, it can seem as though it will never be finished.” “When code is integrated and running, even if the system isn’t usable, it’s apparent that it soon will be. With incremental integration, programmers see early results from their work, so their morale is better than when they suspect that their project will never draw its first breath.” “The visual and intellectual enjoyment of well-formatted code is a pleasure that few nonprogrammer’s can appreciate. But programmers who take pride in their work derive great artistic satisfaction from polishing the visual structure of their code.” “When someone says, ‘This is really tricky code,” I hear them say, “This is really bad code.” If something seems tricky to you, it will be incomprehensible to someone else. Even something that doesn’t seem all that tricky to you can seem impossibly convoluted to another person who hasn’t seen the trick before.” “Your employer can’t force you to be a good programmer; a lot of times your employer isn’t even in a position to judge whether you’re good. If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.” “The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers.” “… humble programmers who compensate for their fallibilities write code that’s easier for themselves and others to understand and that has fewer errors.” “Adherence to a single method is also harmful in that it makes you force-fit the problem to the solution. If you decide on the solution method before you fully understand the problem, you act prematurely. Over-constrain the set of possible solutions, and you might rule out the most effective solution.”