Mental Pandiculation

One thing that I constantly suffer from is letting the concept of perfection keep me from making progress on something. This happens not only in my software development but in my writing, my gardening, my golf game, almost everything. I have no idea how this came to be but it seems to be a pervasive element of my flawed character. I have found that it’s important to constantly focus on identifying when I’m trying to hard for the perfect. Progress, even negative progress, is almost always better than paralysis. I don’t seem to be alone in this characteristic. Take for example this post that is arguing, albeit in an extremely conflicted way, that the concept of Separation of Concerns in software development is useless because a perfect Separation of Concerns is impossible.

Anyone who says that a system must display perfect separation of concerns has either never written any large-scale software systems or is certifiable and can safely be ignored. The goal of writing software isn’t to produce perfect separation of concerns. That is only one of many possible means to get to the end result of long term maintainable software that produces some quantity of value. Writing any meaningful software without an eye on SoC results in a jumbled morass of unmaintainable and untestable crap. Does this mean that your HTML views should be completely dumb, devoid of logic? Of course not and no one with any real world experience would argue that. But if you don’t constantly strive to keep them as dumb as possible, you will end up with junk. It must be a constant focus, one that is in the forefront of every decision because if it is not, it is always easier to do what is wrong than what is right.

When I first read Atlas Shrugged, I was enthralled with the concept and philosophy behind the novel, that selfishness was inherently good and that every action should be judged based on one’s own self interest. Of course, I was 16 and frankly, the philosophy fit nicely into a 16 year old’s limited world view. As I got older, I began to realize that while acting in self interest as a general rule is good, taking it to the extremes that Objectivist philosophy did will result in a terribly narcissistic life.

The same thing happened when when I first discovered design patterns. Everything was a Factory. I loved Factories. Concrete Factories, Abstract Factories, Factory Factories, by God they were all fantastic. But slowly over time, I learned not every thing was a Factory and not every thing fit neatly into design patterns. But as a guiding rule, design patterns are good but it’s just as important to know when to not use one as it is to use one.

Separation of Concerns is the same. As an overall guiding principle, it is critically important. There are going to be times when ignoring it is in fact the right decision but those times are very few and far between and you better have a damn good reason for doing it. But not doing it because it’s never going to be possible to have a perfect separation isn’t one of those reasons.

When I first started doing web development with Visual Studio 2005, it was pretty painful work. Not only was the development itself difficult in many ways (if I say “typed DataSet” and “bloodthirsty bedbugs”, which makes you cringe more?) but the deployment of sites was often a long, tedious manual process for a site of any size. I distinctly remember having to log into my hosting provider, upload a zip file or collection of files, manually unzip or move them around and then hope that everything and the stars were lined up properly. Microsoft tried to make things easier with the Publish technology from Visual Studio but that never worked particularly seamlessly, at least not in my limited experience. On top of all that, it required considerable discipline (and a kickass source control which I’m not sure existed) if you wanted to deploy certain changes but not others.

Take a quantum leap forward into 2011. Over the last 3.5 days, I built a website to serve as my central home on the web, a place where I can aggregate my work, writing and other activities easily. I built the site in Rails, used git for source control and when it came time to deploy the site, Heroku for the hosting. To deploy my site, I had to do to things:

heroku create

and

git push heroku master

When that was done, I had a live, working test site on the internet that I could test in multiple browsers, get feedback on, etc. When I was ready to redirect my current home on the web to the new one, all I had to do was add a custom domain and Zerigo DNS add-on at Heroku, update my nameservers and presto chango, the production site was up and running.

On top of that, because branches are so painless and easy in git, I can create a new branch, work on it, merge it with the master and update the site all from the command line of my laptop. The idea of having to log into a hosting provider to upload files suddenly feels like waterboarding. If you have a significant test suite, it’s a matter of having your tests pass and then just updating your production site. Obviously, as a site grows, it won’t be quite that easy but it’s not going to get that much harder either.

The smart folks at Heroku have removed some of the major obstacles to web development so we can focus more on writing the code now and less on the administrative agony. On top of all that, for small sites like mine, the cost is negligible or non-existent. Lots of things aren’t better in 2011 than they were in 2002 (the world’s going to end next year) but web deployment, if you choose the right tools, is infinitely better in a way that’s almost inexpressible.