Designing from the outside in

27 04 2005

Great post by Tim on the O’Reilly Radar about the importance of starting a design from usability and function rather than from frameworks:

I was talking with Jason Fried of web design firm 37Signals recently. He believes that contrary to the normal expectation that applications are built on top of frameworks, applications should always be designed ‘from the outside in.’ That is, at 37signals, they try to design the usability and function of the application first, and that drives the implementation. And if they can then extract a re-usable framework, all the better. For example, basecamp wasn’t built on top of Ruby on Rails. Rather, Ruby on Rails was extracted from basecamp. This approach seems obvious and commonsense — but hardly common in this era of heavy web services standards-ware designed by technical committees far in advance of actual implementation.

All very true, in theory, however there’s something to be said in favor of consistency. When you use the same framework over and over, you start getting familiar with it, you learn its pitfalls and hacks and you become proficient. Sometimes it’s better to stay with what you know, even if it’s sub-optimal, than risk taking a new road, however promising it looks.

Most of all, you want to avoid falling into “Classic mistake 34: Overestimated savings from new tools or methods.” from Steve McConnel’s classic “Rapid Development”:

Benefits of new practices are partially offset by the learning curves associated with them, and learning to use new practices to their maximum advantage takes time.

That’s why, even if Ruby on Rails looks cute, for my next project I’ll probably stick to my usual bag of tools: Java, Cocoon, Spring, Hibernate, etc. (Note that this bag was not designed by a technical committee, but grew out of many years of experience in developing software projects.) This probably means that while designing the application, I will unavoidably try, at least in part, to fit it into the context of a predefined framework.

I guess this approach fits better the “from the outside in” moniker, after all. We start from the outside (function and framework) and move towards the center (implementation), whereas I would say that starting from the functionality and deriving a framework from it can be better described as “top-down” design.

Of course, it’s entirely possible that once in a while you’re faced with the task of developing a system of a kind you’ve never seen before and find out that your usual framework is not good at all, but I’m sure this seldom happens very seldom, at least in my experience.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: