Chris Cowdery

I used to always be a relentless top-down developer. I deduced that it simply was the best way to go – once you create the interface the client wants, you have a better understanding of the requirements and can get feedback right away which would help cut down potential changes in architecture mid-project. Bottom-up projects often suffered costly redesigns as the client would change their minds after seeing the product and in some cases I’d have to re-invent the wheel again.. and again. After being scarred too many times, I switched over to a top-down philosophy for my app development, and have been doing it for several years now.

The procedure was more or less the same for every project. I would create my user interface in Photoshop and slice it up (or if I’m feeling exceptionally keen, straight to the code), and then piece by piece I would snap little bits of interface together to form an overall gestalt. After many refinements and tweakings, I’d prepare a demo and portfolio for my client and showcase the new interface. If all went well, I’d begin design of my Controller and Model components from then on, giddy with satisfaction that the client liked the demo.

But that’s when the honeymoon period starts to end. Quickly.

The app now has all these lofty requirements and proposed features, and there’s a substantial chasm between the various elements. Solutions pop into your head on how to connect them, some more eloquent than others, but invariably the initial solution isn’t as clean-cut as you’d like it to be. Several pads of paper and pots of coffee later, a nice design emerges for your Controller and you swiftly bind all the GUI elements to their proposed functions. Life is good. But then there’s the Model…

After slewing through the Model, and getting that last unit test to pass, you finally have first release candidate to show to the client. You’re pleased with yourself, glad that you pulled it off and you’re happy with the results, and the client is too. The client then pulls you aside afterwards and was wondering what happened in the past few weeks. Despite the fact that you told them it was going to take a while to ‘do the plumbing’ to connect everything, they expected something working earlier than this, after all – they saw an interface with everything they wanted to see on it! How hard could it possibly be?

Time after time I find that this approach suffers from the Iceberg Effect, in addition to the dangerous waters you have to navigate through to avoid a Frankenstein app and other anti-patterns. I assumed it was the best way to go about doing things (for me) despite it’s shortcomings, and I continued on my merry little way… until this weekend.

What if you didn’t start with the View, or even the Model – and just went straight to the Controller. This way you could start on an app which knew from the ground up the best ways to interact with the Model and also the best ways to interact with the View.

The most essential moment in the development of an application I believe is when you realize how the users intent can be fulfilled, and since this is predominately Controller logic anyway, you’ve basically got the app in the bag. Here are a few pros to this approach:

• You can construct a modular Controller around the users actions and not the nitpicky needs of the app infrastructure
• You still have an understanding of what functionality the user will be able to use in the View
• You don’t need to make any compromises with the design of your model
• You won’t be a victim to the Iceberg Effect
• Can construct unit tests right away for Test Driven Development
• Less likely to paint yourself into a corner since you know the app’s logic and constraints up-front
• You and the client have reasonably high visibility on the project

No methodology would be complete without it’s drawbacks though. Here’s a few which I think can come into play:

• Longer delay in getting the interface ready means that there could be a small back-and-forth between Controller and View handshaking if the client makes repeated changes
• More time needed up-front to flush out the design

So what do you think? Is this a steaming pile of balderdash, or do you think it’s a happy compromise in this day and age of app development? I will be trying it on my next project, and I’ll keep you posted with the results.