Samstag, 29. Oktober 2011

Framework Agnosticity

I recently stumbled upon a blog entry posted by @unclebobmartin on 8thlight.com titled Screaming Architecture (I suggest you read that blog post now if you haven’t already).

While I’m not entirely convinced that it is a bad thing for a rails application to be recognizable as such, one paragraph really struck me:

A good software architecture allows decisions about frameworks, databases, web-servers, and other environmental issues and tools, to be deferred and delayed. A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat or MySql, until much later in the project. A good architecture makes it easy to change your mind about those decisions too.

I really like the idea of not having my application tied to any particular framework. But how to achieve this? If you don’t want to be locked into Rails (or something else) early on, does that mean you shouldn't use Rails at all until very late in the project? Probably not. You do want to build something usable quickly and thus need a way for real world users to interact with your system, so what can you do?
I think that building two versions of the application simultaneously - using a different framework for each one - could be one way to make sure you’re not tied to one particular framework. 
Maintaining two versions of the same application might seem like a pain int the butt at first, but it will hopefully make you move most of your code out of the framework specific parts. Whenever you find yourself duplicating code in both versions of the application, you should feel the urge to put it into the framework agnostic part and just use it in both places. You should end up with a pretty thin layer of, say, Rails and Sinatra code above your business logic.
Of course, it will still be some extra code to write. I view this as a supplementary test (testing the "framework agnosticity” of my code). Not unlike unit tests it creates some additional work that you technically don’t need to build a working application but will help you along the way.
Now should you really build two different web applications? I’m not sure. Maybe it would be even better to use two entirely different approaches like one web app and one fat client (or even better: a command line interface). Anyhow, I’m seriously considering to try this out in my next project.
What do you do to ensure you’re not locked into the framework you use?

Samstag, 23. Juli 2011

I have a blog now

Hello World,

seems like I'm the last programmer who doesn't have a blog and I'm gonna change this right now.
From now on I might be posting some articles here - probably somewhat related to programming - but don't hold your breath.