If you have participated in any way of the software industry in the last few decades, you have certainly seen the pattern of software development. Most software is built under the pressure of deadlines. Specially when a company wants to beat its competitors in a tough market, there is an increasing pressure to deliver software as quickly as possible. And things have not changed much: it was like this with PC software in the 80s, web browsers in the 90s, and more recently SaaS and iPhone apps.
Under such a hectic work pace, many programmers forget what I call the number one rule of developing good applications: always do the right thing. Although it is hard to define what the right thing is, it is really easy to define the opposite situation. If you write a program in a way that you know you need to revise later, and you don’t do this immediately, then you are not doing the right thing.

The main problem with not doing the right thing in code, is that, like in real life, you are creating larger and larger debts in your programming account. As a result, to progress further you need not only to implement whatever feature you originally coded, but you also need to fix whatever was left unfinished. And we are not even talking about the fact that there might be other bugs that you overlooked, hidden in the code you left unfinished.

The power of doing the right thing, however, is great. When you for example write the right function (a generic one), instead of the bare minimum to make the program run, you are creating a basis that can be further used to build the whole program. You are not only fixing an immediate issue, but also saving countless hours further down the development line.
That is why good programming is somewhat non-intuitive, if you not an initiated. To be good at it, you have to code the slow way, at least in the first stages. That is, you have to look for code that not only solves your immediate needs, but that is robust and generic enough that can be used in other situations.
The naive developer will probably try to cut corners and finish the initial stages of the program as quickly as possible. The good developer, however, will take more time to create a really good solution, which will enable to proceed at a much quicker pace in the later phases of the project. 
After some iterations, from the point of view of the naive developer, the good one is proceeding at an amazing speed, which he doesn’t really know how to achieve. The reality is that the speed is just the result of doing the right thing several times, and using the results of each step to provide the foundation to the next software layer — and doing this with increasing confidence. While this virtuous cycle continues, the naive developer is still sorting out issues that he should have solved long ago…

Similar Posts:

• Is Code Reuse Always a Good Thing?
• Native-looking programs in Smalltalk with WxSqueak
• Learning from Great Developers
• Day 18: Development Speed is Important
• Making the Compiler Work Harder for You