How to write perfect code all the time

The most important thing a programmer needs to learn about is how not to make their lives a living nightmare.

This is bad:
Working extremely long hours on projects that fail because you’re always behind because you are always fixing bugs trying to meet impossible deadlines.

This is good:
Working 9 to 5 on successful projects where you hardly ever have to fix bugs where your customers are happy with the timely delivery of features.

Now some would say, you don’t have much say in the matter or that there is some kind of magical programming practice you can adopt to reach this nirvana.

I would say that most of what anyone could tell you is pure B.S. If there was such a thing then 75% of all software projects would not outright fail or be a miserable death march.

I will tell you this, the root of all evil in computer programming is this statement:

“All programmers will make bugs”

Now, this may very well be true, it’s going to happen. However, it has just become an excuse for every programmer to throw up their hands, roll their eyes and not even try. You think it is “impossible”, no one can write “perfect” code goes the chorus. So, you think it is OK and perfectly expected that the QA department will catch your unavoidable bugs and you fully expect to work on bugs reported in your code.

This is SO incredibly wrong and is the one thing you should “unlearn” as a programmer. It is, in fact, possible to write nearly perfect code. By that, I mean that over the course of say 3 months, no bugs have been reported in your code, no hotfixes have gone out. Maybe once in a blue moon a defect happens, but generally 99% of the time, your code sails through QA with nothing found. The only bugs you fix are the ones that other people put in the code that were reported by customers.

I can see you rolling your eyes already, but I assure, it is very possible because I do it routinely, furthermore it isn’t something that only I can do, nearly all the members of my team also do it as well. Everyone I’ve trained does it. The only thing our QA team does is say testing is “done”. We do hotfixes so infrequently that we forget how to do them.

So how do we achieve this nearly miraculous result?

First, you have to take the attitude that you can actually create perfect code every time, all the time. Now this doesn’t mean that you create perfect code the first time, it means you test your code completely enough and debug it so by the time you check it in, you are confident it could go straight into production.

There are some secrets I can share.

The biggest cause of failure in any software project is the “long” schedule. The longer you take before you ship to customers, you exponentially increase risk of software project failure, period.

Therefore, the first big secret is short release cycles. It may seem crazy at first to go to something like a monthly release cycle, but believe me, this makes it almost impossible for a software project to completely fail. I have not actually seen a major software project failure since the adoption of short release cycles. Fortunately, agile methodology is all the rage and while most of it may seem silly, the adoption of the short release cycle and its mandate that the software be fully working at the release has been a godsend. I think this is because it makes it impossible for ‘garbage’ to accumulate in the project. It is this garbage of unfixed bugs, incomplete work, and plain old ‘cruft’ that ultimately hardens the arteries and gives your project a heart attack. If you are ‘clean’ at the end of each release (as you must), then this simply cannot happen. It’s like if you clean your house every week, then you won’t end up with a hoarder’s house at the end of the year.

This short release cycle will force you to break up your projects into tiny bite sized pieces. Of course, you may object that there is no way you’re going to create that gigantic new file configuration interface wizard thing in a month. Well, honestly, most of your project you will get in your professional career aren’t like that, most of what we do are small incremental changes like fixing a bug, adding a button, modifying existing behavior. Generally speaking, every separate work item you get, should take a single person, no more than few days. The number of lines you actually change is typically less than a few dozen. That is, if you are breaking the problem down into these small little chunks. There are exceptions, but you absolutely need to avoid large work items that take multiple people and multiple weeks. My team has been working on projects for years and while it may seem daunting, we do manage to break up the work into these tiny manageable pieces. You just have to have the mindset of what is the smallest thing that I could do in a short while that would be useful.

The way you handle the gigantic problems is to put a variable in your system which hides the functionality while you are working on it. You then implement a myriad of tiny incremental changes to setup the framework, and add the API’s, the buttons, the pages, the save and retrieve logic and all that stuff in to tiny packets which take a single programmer, no more than a few days to accomplish. You can do that, can’t you? Everything you create at the monthly release cycle is incomplete, but fully tested and functional for what has been implemented. When you’re completely done, then flip the switch and expose the new functionality to your customer.

You also need to learn how to get your management out of this “big release” that must be delivered by X date mentality. Instead, have them think, what can I deliver to my customer of value this month. If you can get them to do this, you will never be staring down the barrel of an impossible deadline which will kill the company if you don’t deliver and put you on a death march.

Now, here is the absolute secret to producing perfect code every time. Since you aren’t changing many lines of code at any given time, before you check in your code, do a diff and carefully review every line of code you changed. This is why the tiny work unit of less than a couple dozen lines is critical. You cannot do this with a 1000 line change. Write down the filename in your check-in notes and for every line of code you changed, write a simple “verify” statement that assures that the code you changed will be executed. These all begin with the word ‘verify’ and these are very simply stated such as:

“Verify that if you press the delete button on the red row, you see the row disappear”.

Then make sure you actually run that test yourself. If you made a mistake in the code, it will be on one of the lines you changed. You might think that a simple singular code coverage manual test wouldn’t work, but 99.9% of the time, it will allow you to see and correct any bugs. It forces you to think about how things interact in order to get that code coverage and unearth hidden interactions. Every bug that gets into production is really a failure of the programmer to adequately review and test their code. The quality finger ultimately points at YOU! You’re the one who is closest to the problem and knows what to test better than anyone else.

Your QA people will love that you provide such details since this will clue them in on the areas that have been modified, and shows them exactly what is the relevant functionality that needs to be tested. This greatly increases the chance that your tester will find any defects if they are concentrating on relevant tests, not everything under the sun.

Believe me, if you adopt this very simple practice of self code review, writing down the files changed and writing the simplest and smallest set of manual verification tests possible, you too can write perfect code, every time. When you get it right the first time, every time, it makes everything go so much easier. The average software team spends something like 67% of their time in rework. That basically kills agile methodologies and schedules. That can be reduced to practically zero. Don’t be fooled into thinking it can’t be done.

So, in conclusion, these are the most important things you must learn as a computer programmer:

1. Work on short release cycles
2. Break the work up into very small pieces
3. Self code review every line that was changed carefully.
4. Write a short verification statement that guarantees code coverage

If you don’t believe me, then try it, you will find it to be true.