A Pragmatic Approach to Software Development

I have learned a lot while working as a software developer for the last 15 years in both the public and private sector. There is one mantra that has really stuck with me as I have seen it hold true time and time again, and that is: "good, better, best." You may have heard of this before in the context of pricing model tiers for a service. The car wash up the street from me does the following: the "bronze" service gets you an exterior car wash, the "silver" service also cleans the interior of your car, and the "gold" service gets you fragrances and the promise that even dog hair will be thoroughly removed! Don't fall for that last bit - dog hair is furever (sorry, not sorry). But what does "good, better, best" mean in terms of software development? I am talking about code quality, and the order matters - start off with good code, then move on to better, and save the best for last. This may sound obvious, but I have seen many talented individuals (and teams) spend far too much time engineering complex solutions to simple problems.

Let's start off with the "good" code. Simply stated, good code is not great. It may not be the most performant, it probably isn't scalable, and it definitely does not have a high degree of unit test coverage… but it is solid. It is reliable, it does not have bugs, and it satisfies all of the specification's requirements. You know that new feature that you're working on - the one that is sure to be the "next big thing"? It might not be! So don't spend an excessive amount of time over-engineering it. Work with the business to determine what the minimum viable product is and build that as fast as you can. There is tremendous value in getting code into production quickly. The viability of the business idea can be tested by customers or clients, new features or requirements can be uncovered, and most importantly - you can beat your competition to the punch. If the original idea behind the code you are writing has value, you can take the next step.

Better code - but what makes it "better" than the good code discussed previously? Better code takes newly acquired domain knowledge into account to plan for a future state. "But wait," you might be thinking, "we should have done it right the first time!" That may have been true if you already had a thorough grasp on the problem that you are trying to solve and an understanding of the ramifications of every design decision facing you when you began the project. In my experience, this is rarely the case. Now is the time to start considering your design and architecture. Why? Because you have learned from the first iteration of the feature. Your decisions about where to focus development efforts are more informed at this stage than it was while you were writing "good" code. 

So what defines the "best" code - how can it be quantified? This code takes into account every nuance and edge case in the knowledge domain to the point that it can and should be packaged and sold as a service. When do you take the time to write that code? You'll know because the feature will have already proven itself to be the "next big thing." Until you get to this stage of the game, think carefully about the amount of time and energy you are spending on the task at hand and remember that, in general, perfect is the enemy of done.