The Best Code

Jeff Atwood triggers another thought process about what is the best code. Usually these things are not discussed explicitly, you will always find them embedded in a developer’s preferences, programming style or philosophy. Whenever they are discussed, it is more in relative terms, never absolutely.

I agree with Jeff that the worst enemy of a software developer is the self. But I would like to qualify is further – the worst enemy is the self who does not know purpose of the code. Not the technical functionality, but purpose of the code in the bigger picture. Without this there is no way one can decide on the balance that Wil Shipley talks about.

I think a lot of developers out there know that the balance has to be achieved. What is lost is the proportion of the different ingredients. And it is impossible to decide on them unless you appreciate the dynamics in which the entire software, not just your code, will operate. The project deadlines impact business deadlines, the budget affects the finance, the functionality affects operations, the design affects the usability and most importantly the software solves the business problems and provides ROI.

It is not very intuitive to think about all this, especially when you are supposed to be a programmer. I used to consider this has a hassle when I started programming. For the love of code, forget the business was my appeal! Gradually I did realize though, that the code by itself is not valuable, its usage is. This itself brings out that whether the code is good/best/functional or not cannot be decided by looking only at the code, but at its application. I feel like I am pimping this a lot of times here, but I truly believe that viewing software as a solution to a business problem and treating your customer as a business can highlight this and help you in considering various factors in the balance.

Nowadays, the equation of software development has been affected by another movement – the open source. I like to dig around a bit before I write even a single line of code to see whether someone else has already done it. Even if I cannot adopt everything, it usually helps me in starting off. Again, I have seen people getting lost in the research, forgetting that the final aim of the activity is to deliver the solution. And I believe that these activities will keep changing with time and eras of software development. What will not change is the fact that the software’s value is in being used, and used right.

I believe, the best code is the one with the right balance, and the right balance is the one that solves the business problems and provides maximum ROI.