Just like Top Gun’s Maverick and Goose shrieking into harm’s way in an F14 Tomcat, our lives as developers are always lived on the razor’s edge of speed and utter perfection.
| Maverick: “I got the need … the need for speed.” |  |
We are constantly pushed by customers and ourselves to code faster and faster, often ignoring that what we’re really doing is partly science, partly discipline and partly an art form. Because of this relentless internal and external pressure we cut corners and sometimes, unfortunately, we make mistakes that can often have dire consequences. In Top Gun, Maverick found this out when he took a calculated risk (cutting a corner) and ended up with a destroyed fighter and a dead friend.
While young programmers are always susceptible to this, the problem can happen even to developers who have years, even decades, of experience under their belts. That’s because with all that experience comes the false sense of security that you are no longer capable of making a rookie mistake – so it’s OK to cut that corner. Feeling safe and secure wrapped in all that experience, you allow yourself to pump out that code as fast as you can to satisfy your customer’s ravenous appetite for more code turned around in shorter times – and most of the time it works … until you lose focus for just a moment and a bug slips through the cracks. Those are usually the worst kind too.
As a developer at any stage in your career, the best things you can do to safeguard yourself against falling into this trap are:
Understand the Requirements
This sounds so obvious, but it’s alarming how often developers don’t have a deep understanding of what it is they’re being asked to do. Ensure that you have a complete understanding of the requirements before your fingers start hitting the keyboard.
In addition to that, ensure that your customer has a complete understanding of the requirements. This may sound strange at first, but it can happen that a customer gives you a requirement that isn’t fully thought through. You can always tell when a customer is fuzzy on their own spec, because they will waffle on details when you start questioning them about scenarios surrounding the requirement. When this happens, it’s up to us as developers to ask probing questions until all corners of the requirement have been explored. Remember, we’re trained to think this way. They’re not. If we say nothing and just code to what’s on the paper without asking any questions we’re as much to blame as our customers.
Proper Estimation
Estimating development time is always hard – especially for developers. As engineers, we always want to say we can deliver faster than is realistic. We’re our own worst enemies because we think that smart people can deliver something quicker than dumb people – and none of us want to be labeled as dumb. But in doing this, we are being dumb – really dumb – because not only are we giving ourselves too little time to code properly, but we are also severely tempted to cut corners when the clock is ticking and our deadline (not to mention our ego) is on the line.
The customer, of course, is thrilled to hear that you can deliver perfect code in some ridiculously short amount of time. Who wouldn’t be? They can report back to their boss that not only are they able to deliver under budget but that they’ve also found some hotshot developer they can use for other projects who can deliver faster than anybody else in the known universe. This is awesome!
But it’s not. Because it seldom works out that way. When you under-estimate, not only are you probably not asking questions, but you’re rushing through your logic, you’re not documenting your code and you are probably either doing quick, high level tests or no tests at all. When you take a step back that definitely sounds like a recipe for success doesn’t it?
I once had a Project Manager who said he took every developer’s estimates and multiplied them by pi. For those of us who aren’t smarter than a 5th grader, that’s 3.1415926535… ok, ya, I get it. His point was that if you want to allocate proper time for understanding requirements, documenting your code and testing you should multiply your gut instinct as a developer by a factor of 3. If you still have a deeply ingrained need to be regarded as the god of programmers, you could always take a page from Star Trek:
|
Kirk: “Mr. Scott, do you always multiply your repair estimates by a factor of four?”
Scott: “Of course sir. How else to maintain my reputation as a miracle worker?” |
 |
Did you test? Are you sure? How about now?
As developers, we’ve all heard that the best way to guard against bugs is to test. We’ve heard this over and over and over again.
But were you listening?
When you have time on your hands, building test scripts is easy. However, when you really need them is when you don’t think you have time. It’s like when you play basketball and you’ve got 100 guys coming at you and you just blindly fire off a shot … and it doesn’t go in. If you would have just taken that extra moment to aim and then shoot you would have had a better chance of making the big play, winning the game, getting the girl, that big movie contract and winning the lottery.
OK. Maybe I’m exaggerating, but the point is that building repeatable unit tests is critical to the success of any project. Without them, you really don’t have a good way to know if your code works in positive, negative, max and min scenarios or any other scenarios for that matter. If you’re just doing a quick test odds are that’s it’s a Happy Path test – but that’s not where the bugs usually hide. They usually lurk in the scenarios that are a little harder to test for that “almost never happen.” If you accidentally put a never ending loop into your code – guess what – that’s exactly where you’ll find it.
Conclusion
Our conundrum as developers is the Project Management Triangle. To quote Wikipedia
|
You are given the options of Fast, Good and Cheap, and told to pick any two. Here Fast refers to the time required to deliver the product, Good is the quality of the final product, and Cheap refers to the total cost of designing and building the product. This triangle reflects the fact that the three properties of a project are interrelated, and it is not possible to optimize all three – one will always suffer. In other words you have three options: |
 |
• Design something quickly and to a high standard, but then it will not be cheap.
• Design something quickly and cheaply, but it will not be of high quality.
• Design something with high quality and cheaply, but it will take a long time.
Our goal as developers should be to stand for high quality wherever possible. The long term cost of low quality code can be high. Imagine if low quality code were running our nation’s new air traffic control system. I think everybody wants to ensure that the developers on that team took their time and did everything right.
|
As developers we always live on the razor’s edge of speed and utter perfection. Always remember that just when you think you don’t have enough time to do it right – that’s precisely the time when you need to do it right.
|
 |