Taking the Bullet

James Gosling wrote a blog entitled "Sharpen the Axe: the Dark Side". You can read the blog for yourself, but the quick and dirty is that we all can get too caught up in the path taken instead of the destination. Although James was generally describing tool development, I believe the same can be applied to application development and pattern usage.

James references a quote from Abraham Lincoln, "If I had eight hours to chop down a tree, I'd spend six sharpening my axe." While improving your situation through preparation, it's very easy to over prepare yourself without fully understanding the problem at hand. Let me rephrase that, while improving your situation through patterns, it's very easy to over engineer your application without fully understanding the problem at hand.

To continue the axe example, lets say you did spend all that time on sharpening the axe. Is that axe going to now cut everything for you? The same can be applied to object oriented development as you will soon realize the scary truth that no object model is best suited for all tasks.

Even though you spent four weeks of meetings on defining your Account object, in the end it probably won't be the best object for handling both large fetches for a view and coordinating long transactional processes. How do we find the best solution? We don't. We "cut down that f*cking tree" and then spend that extra time adapting to the next task-- if it's cutting down more trees, then by all means sharpen your axe. If there are no more trees to cut, then we have six hours to watch most of the extended edition of "Return of the King".

Robert Martin uses the quote "Fool me once, shame on you, fool me twice shame on me" --or use some other variation from President Bush. In order to save time and protect ourselves from needless complexity, we allow ourselves to be fooled only once. By letting ourselves get fooled only once (or taking the bullet), we can more rapidly move on to the other tasks. The longer we wait to fully realize what kind of changes are likely, the harder it will be to create the appropriate solution.

This methodology can go south on you but change can be harmless when you have very short development cycles. Get solutions created quickly and move on to the next, dependencies and change will present themselves as if you are reading between the lines of all your requirements. Other ways you can protect yourself is to use simple OO programming tactics such as the open/closed principle, the single responsibility principle, and the Liskov substitution principle. If you didn't put the world in the hands of that framework or object, it's not such a big deal if something in the world changes.

In summary, the basic idea is to take the bullet and develop some solution that best fits the task at hand, while not wasting time rolling out a bloated mess. This is not an excuse for poor programming style. Being able to resist premature pattern usage and abstraction is just as important as using patterns and abstraction.