Quick and Dirty

Have you ever noticed that almost all examples of people divide them into two camps?  Those that can do math, those that can't, etc?  Well, given the confines of a blog post, I'm going to use the simple model of two opposing camps to make a point about getting work done and two wildly different approaches.

There's the camp I belong to - the quick and dirty camp.  If I have a project to do, I try to find the solution and go to it directly, to "prove" the work can be done, then backtrack and fill in the loose ends.  When, in the dark recesses of my youth I did programming, I would always write the bare minimum code to see if I could get the "gist" of the requirements, then go back and flesh in the other pieces.  In this approach you can very quickly prove out the model and flesh in the skeleton afterwards.

There's another approach of course - and that one is the flesh it all out as you go along.  Rather than try to prove out a model in a quick and dirty approach, these folks will build out the entire solution as they go, and sometimes get to the final bits and pieces and recognize that not everything fits they way they thought it would.  I'm sure there are times and places where this approach makes sense, but in an engineering or development environment it can be very tricky to do.

Usually, especially if there are several important moving pieces or applications involved, I'd rather see a cobbled together but complete end to end solution that works as quickly as possible, and then flesh out the documentation and user interface and so forth, rather than the full design development followed by coding and documentation and so forth.  Why?  Because I can find out fairly quickly whether or not the concepts will work, and how hard it will be to make them work together, and determine a different path if necessary early in the process.  Taking the second approach I can be well into a project before I discover a significant stumbling block.  For example, if I am integrating an application I wrote to a third party's application and simply assume a data model is accurate, I may find late in the process that my assumptions about the other data model were innaccurate and will cause me significant changes to my code.  If I had built a simple integration to that third party application and tested it, I would have understood very early in the process the challenges that I now face much later in the project.

I don't think that these two approaches are learned - I think they are almost innate.  Some people are more likely to be tinkerers and prototypers and willing to live with minimal application support as long as the application works.  Others insist on a complete and rational development approach, fleshing out everything in its turn.  I think that the quick and dirty approach is often a better one in product development, whether that's "hard" products or software, since I'd rather fail early and incorporate that learning than to fail late.