Mike Spille has written a blog entry that captures the essence of the battle between pragmatism and perfection, in "Ember, Eeyore, and the Mad Cow
It's intern season at work, and working with people who are fairly new to the business has caused me to consider more deeply what software development's all about. If you look at sites like TheServerSide, or read the mountain of books out there about software development, or even silly blogs like this one, you constantly see deep discussions about design, architecture, scalability, performance, testability, maintainability blah blah blah. You might get the impression that developers work in these high tech, pristine offices and are paid to Think Deep Thoughts.
Or maybe you're more of a slashdot fan. Unlike the squeaky clean Deep Thinkers you read about the Obfuscated C contest, the least amount of code to write a web server, hacking into the phone system with an old sock and a gum wrapper, and deploying a successful e-commerce site on the web with 3 lines of code via Ruby on Rails.
I think the reality for most software jobs spans across both of these viewpoints. For those of us who speak more on the Deep Thoughts side - well, your average guy in IT doesn't spend all day every day diagramming architectures and arguing OO design or critiquing marshalling techniques. Or checking 2-PC state diagrams or the nuances of async event notification via NIO. Some days may be spent doing nothing but fielding support calls. You might lose several days tracking down a single bug. You may even find yourself putting together a quick and outrageous hack to meet a deadline or to hold production together long enough for a real fix to be developed and put in place. And at the end of some days you may look back and realize you did litle more than surf the web and take a break for lunch.
He then goes on to describe what it took to fix what was originally just an obscure bug - one not addressed by containers or dependency injection or (gasp!) the JCP.
[The debugging effort] involved lots of guessing, thinking, arguing, running SQL queries, starting at reports, and hacking together truly ugly scripts to try to pull all the pieces together. A hunk of it was fairly pretty - the initial automated comparison program. But most of it was plug ugly.
His final paragraph is a summary of the job, in a dramatic nutshell:
But this is the job. "Make it work and keep it working". All the skull sweat comes from interpreting that phrase - what does it take to make it work, what does it keep it working, and how do those two priorities interact with each other. At a stupidly high level, what this means is that in some situations you want to be in an ivory tower, puffing on your pipe while you argue abstract ideas around development methodology, and system architecture and code design. And in other situations you put on your filthiest blue jeans and start crawling around in the innards of your system, banging on pipes and checking fluid levels and getting yourself dirtied and soiled while you try to find out what's wrong with the beast. It's a mad mix of fore-thought and off-the-cuff, careful planning and snap decisions, dealing with the long term and the "right now!". To ultimately succeed you cannot afford to be one person with one view, but 3 people, or 7 or 8 or 40, or whatever number it takes to fit the reality. In the end all that matters is "Make it work and keep it working". And ultimately if you won't do it they'll go and find someone who will.