View First

I’ve been working on an experimental side project using Rails. The project details aren’t important since today’s subject is generally applicable to software development. I started my project by specifying a few domain objects. Two objects to be precise. This is the typical way that I work–it’s very DB centric. While working, I noticed that I was doing a lot of guess work. My user stories and UI sketches were gently hinting that the model wasn’t the logical next step. After a brief pause, I decided that this experimental project was the perfect opportunity for an experiment.

I switched focus, and fired up the HTML/CSS machine. As difficult as it was, I put a freeze on writing any new code. I found it refreshingly easy to translate user stories into views; my progress was natural and effortless. The resolution of a user story is adjacent to that of a view. Both view and user story are centered around how a user should interact with an application. Working on the view undoubtedly shortened the feedback loop that’s critical to an Agile development process. I wasn’t creating any behavioral code but I was developing very real HTMl and CSS. I wasted no time guessing about database fields or needless architecture.

When I was finished, I had views that visually represented my user stories. Starting with the view first eliminated waste that I would’ve normally accumulated at this point in a project. I was able to evolve requirements quickly without throwing away globs code. To further illustrate my point, the simple domain objects (and corresponding tables) I started with required modifications to remain inline with my evolving application.

The only thing left for me to do now, is test and code the behavior required by my views.