Archive for September, 2004
Code Complete 2 – Essential Reading
Sep 7th
If you only buy one programming book in your life, buy this one.
Many of you will have heard me rave about Code Complete and Rapid Development. These are both by Steve McConnell and my successful programming career owes an enormous debt to them, most of my ideas on projects seeded from these books.
Back in 1997 the first revision took me over three hard months to read. Much of the material was new to me, and it really took time to sink in – some of it never clicked. Fast forward to June 2004; The Second Edition grew about two hundred pages to incorporate new fashions on the block like xp, refactoring and design patterns. I ordered it ASAP but only just found the time to read it.
Despite ten years having passed since the first edition, many fundamentals have stayed the same, and it looks like some chapters were only lightly updated. This is proof of how good the first edition was. Personally I read the first edition about four years after completing a post-grad degree in Comp Sci. As I said there were many sections that I just did not understand fully. It is now eleven years since the degree, and the book was a total pleasure to read. So many partially illuminated light bulbs are now glowing brightly. Yes everything in the book is pretty basic stuff. The Design Patterns/ Extreme Programming/ XAML/ Avalon/ only-in-pre-Alpha release crowd will not be impressed, there are few new buzzwords to impress people with. IMO it is far more important to have good grasp of the basics before we go out looking for new hammers to use on our next project. How many of us have seen a Design Pattern used inappropriately, just because a developer happened to read about it lately?
The book is only $34 from Amazon and Steve has made some chapters available for free.
Defensive Programming
Sep 7th
GIGO, Garbage In, Garbage Out; Even before my first high school Computer Class back in 1982 this term was well known to me and my few programmer friends. It is up there with Goto considered harmful. This blog tries to explain the why GIGO is no excuse for failure in your own code:
Recently, while on a group cycle ride a fellow rider’s lack of experience/ judgment in jumping a road hazard led to reasonably serious injuries on my part. Was it my fault? Well, he lost control while jumping falling on my bike and taking it down. Still I partially blame myself; I had never seen this guy cycle before, and just assumed he knew how to hop a bike over obstacles. In future when such an obstacle arises, I’ll be very alert for problems and maintain a good distance from unknown cyclists when potential danger arises.
We can do the same in programming. The recent Fail-Fast post highlights one such technique. In Code Complete 2 Steve McConnell collectively groups such techniques as Defensive Programming. This chapter should be read by anyone who writes code for a living. He correctly points out that a fail-fast technique is not always the correct action. Over the last eleven years I have exclusively written serious business applications that often work with financial data. In these cases if an error occurs we would rather fail in a hard manner than have the code work in an inconsistent state:
“A dead program normally does a lot less damage than a crippled one”
But, what if you are writing a video game, or the error happens in simply rendering data to the screen. In such cases a graceful recovery option may be better. Would you rather have Windows crash, or show a desktop icon using the wrong colors?
The chapter is too long to do justice in a blog post. It covers sub-topics including Assertions, Barricades, Graceful Recovery options, Robustness v’s Correctness and Exceptions. At the bare minimum skim-read all the sections (although the Exception section is pretty weak IMHO).
Certainly one project I participated on in 1997 suffered politically because it was the GUI to a lousy messaging system, which feed the GUI with bad data. My manager’s defense was ‘Garbage In, Garbage Out’, and it fell on death ears. With the hindsight of Steve McConnell’s wisdom, if we had Barricaded our code from bad data then fighting politics would have been much easier. The manager could have attended meetings with
the log from the Barricade Layer, proving in black and white where the problems lay. Both teams would then have been able to solve the problems much quicker, without escalating it up the management chain.