The Enemy of the Great

They say that perfection is the enemy of the great and this is very true in software development. I used to believe that there was no such thing as the perfect design but now, after years of studying design, I think in many situations there is such a thing as a perfect design. The problem is that it is usually so complex that we would never want to implement it. But knowing it exists points us in a direction and gives us options for refining our design as needed.

I am known among my colleagues as a patterns guy but I use patterns only as needed. I know I can always refactor to patterns later so if I don’t have a requirement that need a pattern I will not use one. Doing the simplest thing is usually the best thing for now as long as my development practices don’t paint me into a corner.

When I teach design in my courses (http://techniquesofdesign.com/training/) I like to show examples of what good design is but I know that a lot of the time we are in situations that are so high pressure we just want to get something out the door that we are not too embarrassed by. But I find if we have a grasp of what good design is then we are far more likely to get close to it even when the pressure is on.

One of the most dangerous and inaccurate myths in software development is the idea that good development practices are much more time consuming then taking a “quick-and-dirty” approach. Sure, we have to make compromises when we develop and knowing the right compromises to make is an important skill to have as a developer, but often “pay now” verses “pay later” turns out to be “pay later and pay sooner than you ever imagined”. We can comfortably abandon gold plating but there are certain things that we should not abandon, even when pressure is on get something out the door.

When I study the truly great developers that I’ve had the privilege to work with there are certain things they do not compromise on ever. This is true in other fields as well. You will not find a construction worker decide a blueprint is too much trouble to fully execute or that certain materials called for in the Handbook of Civil Engineering are really not needed. When a 2’ x 8’ beam is called for in a support column it is not acceptable (or legal) to replace it with a 2’ x 4’ beam. The problem is in software the rules are not so cut and dry or even stated most of the time.

I met a chef once who told me he didn’t have time to be sloppy. When you prepare hundreds of meals in an evening you don’t have time to make your kitchen a mess. You must find ways to work sustainably. The same has to be true for us in software development.

Let’s face it, sloppy code is not really the right way to cut corners. Perhaps we should look at scaling back some features or at least changing their priority based on customer feedback since nearly half of all features put into software are never used anyway.

I am still surprised when I go into development shops where the developers live in a constant death march. Writing software should be sustainable. That is no way to build a career or to build a product.

Unfortunately, we developers sometimes get a bad rap among managers who see us as geeks striving for perfection at the expense of their schedules. In my experience this is rarely true. Most of the developers I meet are pros and we want to do our best but realize there are always compromises so we strive to make the right ones.