Living in code

If you care about software engineering as a practice, and you care about being a g{ood,reat} software engineer then you have probably read Fred Brooks' seminal article on solving the essence of software engineering problems. This article was written in 1987 and as I was reading it over again this afternoon it was as fresh to me as when I read it in college (thanks Professor Werner) in 2001, and still as fresh as it must have been in 1987. To put this into perspective, in 1987 I was 6 years old and Microsoft released Windows 2.0.

That being said, the reason I was re-reading this article is because the other night I finally got a chance to spend some real time with Ruby on Rails. I, as most people I have talked to, was blown away when I "got it." Rails makes writing database backed web applications simple, straightforward, and alot of fun. I hope it stays this way. In my opinion the worst thing that could happen to Rails is for people to start looking at it as a hammer and every project they get put on a nail because, as Fred Brooks has pointed out, there is no silver bullet and there isn't likely to be one anytime soon.

Rails can't/won't slay the Werewolf that is software projects but it is pretty adept at slaying one particular kind of beast. Rails is not the "silver bullet" but for database backed web applications (with AJAX, I might add) it is golden. Writing software is more like taking on every mythical beast known to man than it is like slaying a werewolf. So we could say that DB backed web apps are vampires, and Rails is the wooden stake that we can drive into its heart. I think that's a fitting analogy for Rails because it does go straight to the heart of the problem you're trying to solve. It's a little peice of our software engineering arsenal to be used in specific situations. Kind of like how nearly every boss monster in nearly every single video game I played growing up, and I played quite a few, had a particular weakness that I could exploit to achieve victory.

As software engineers the sooner we stop looking at all software engineering projects the same way the better off we'll be. I'm not the first one to say these things. We have to be actively on the lookout for more wooden stakes. More weapons for our arsenal. As creators we need to identify the applications we build time and time again and create frameworks like Rails to help us slay those beasts because if you've used Rails you know that when your project falls into the Rails sweet spot you've got a good opportunity to knock it out of the park EVERY SINGLE TIME. The reason for this is that the less code we write, the more time we can spend on solving the essence of software systems as pointed out by Fred Brooks. Now to quote from the article a bit

• complexity - Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
• conformity - Software people are not alone in facing complexity. Physics deals with terribly complex objects even at the "fundamental" particle level. The physicist labors on, however, in a firm faith that there are unifying principles to be found, whether in quarks or in unifiedfield theories. Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.
• changeability - The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superseded by later models, or essential changes are incorporated into later-serial-number copies of the same basic design. Call-backs of automobiles are really quite infrequent; field changes of computers somewhat less so. Both are much less frequent than modifications to fielded software.
• and invisibility - Software is invisible and unvisualizable. Geometric abstractions are powerful tools. The floor plan of a building helps both architect and client evaluate spaces, traffic flows, views. Contradictions and omissions become obvious. Scale drawings of mechanical parts and stick-figure models of molecules, although abstractions, serve the same purpose. A geometric reality is captured in a geometric abstraction. The reality of software is not inherently embedded in space. Hence, it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics.

There you have it, straight from the horse's mouth. To get back to how Rails fits into this lets look at what it does for the above issues:

• complexity - Rails dramatically reduces the complexity of database driven web applications
  
• conformity - Rails' notion of convention over configuration gives us guidance and a model to conform to.
  
• changeability - ActiveRecord's ability to introspect database tables and automagically update models when the underlying database schema changes reduces the impact of software change.
  
• invisibility - Not so sure Rails helps here, feel free to chime in and tell me how I'm wrong.
  

3 out of 4 ain't bad!

What is the single most important thing that we can take with us from Rails when we have to do something other than database driven web applications? Find more weapons! Build your arsenal!! As Dave Thomas of the Pragmatic Programmers has pointed out in his talks and books "Build your knowledge portfolio." And as you do, be on the lookout for wooden stakes, clubs (to smash zombies heads w/), silver bullets (for when we DO run into werewolves), water (for the wicked witches), and whatever other mythical weapons you can find for solving the task at hand.