Building it Front-to-Back
How many times have you experienced this: A gaggle of developers working feverishly for months, all the while, stakeholders asking, "Can we see it yet?" "Nope.", comes the reply, "We're still building the system that the UI is going to sit on top of." Then, one day, "Tada! Here's the UI!" "But that's not what we wanted!" Oh oh. (Or best case, the UI is functionally sound, but looks like ass because you're too pressed for time to polish it up and make it esthetically appealing and ergonomically friendly).
I never really thought to question it before. Not until I had the complete freedom to try it a different way, without having to fight to convince anyone that doing things in reverse might actually be a better way. I'm building a large system front-to-back right now (user interface to data storage), and am thrilled with all of the benefits this approach is offering.
Most people in development know that the last things on the project schedule are the things at most risk of being cut in a time crunch. Most development projects see the bulk of the user interface being developed after all the system work has been done. But the user interface is the only thing the customer sees - it's what they buy. See the problem? You're leaving the most important thing to last. This is way too risky, for you and your customer.
The idea that you can reduce an application design down to a bunch of nicely written Word documents is nice, but not realistic. Try and try again, with this approach, it'll never match having a living breathing example (UI) of what you're building, while you build all of the system architecture level things that no-one else gets to see but us developers.
Not that you shouldn't spend a really sizable chunk of time designing and building your architecture. (See my last post on architecture). But rather, the architecture should be derived from a living mockup, or UI design. Not just screen caps (not enough), and not necessarily a full prototype (too much, and too likely to get thrown into production), but something in the middle.
Here's the steps I followed with my current project (a web-based modelling tool, built to be hosted ASP style; = large scale deployments):
- Started in Excel: 'cause it's a data modelling type tool, so I wanted to layout the main tables and views that people would have available to them
- Moved to Photoshop: to put some lipstick on the pig and make it look pretty (don't forget, esthetics sell)
- Got feedback on the concept - Was the concept right? How does it look? Good. Ready to proceed.
- Got feedback on the interactivity - how does this behave compared to regular web-apps? What do you think? Good. Ready to proceed.
- Moved back to PowerPoint: I wanted to mock-up every single screen in the application so that I could get feedback and make any changes quickly without having to rip-out months worth of coding. PowerPoint is great for UI design because you can throw in image pieces and move them around with text and rectangles quickly. And with one-slide-per-screen, you can still have 60 screens in one file, with annotations, printer-friendly, and sharable.
- Got feedback - How does the functionality set look? Anything missing? Anything wrong? Good. Ready to proceed.
- Got feedback - This was the single most important feedback stage, and allowed me to get the detailed kind of comments that would only otherwise be available at the end of a development cycle (when it's too late), because the application "appeared" to be complete, from the user's perspective - just that it was all dummy data. At this point, beyond looking at screen caps, they could actually click around and "use" it.
- Business Logic and Back-end: Now things start to look like a normal development cycle from here-on-in. Do your architectural design, but this time with a living specification staring you in the face (one that the customer has actually approved), and proceed to implement it.
With this approach, I've pretty well eliminated the risk that the product won't match customer expectations because they've actually been able to see it and play with it before I go do the lion's share of the development. Not only that, but now that I'm building the back-end, while I still want to build a somewhat future-proof architecture and be fairly generic with it, I have an extremely specific, living example of the application I ultimately want to build with it.
Some might call this rapid prototyping, but there are a couple important differences:
- Only the UI was mocked up: do we really need to demonstrate that we can read and write from a database? No. Skip that stuff. Just mockup the screens and connect them so the user can get a feel for the navigation. Populate the screens with dummy data.
While the goal of this approach was similar to one of the goals of Extreme Programming (get the customer in early), I think the approach is stronger because while you get all the benefits of the user being involved early on to validate what you're doing, you don't have to sacrifice the benefits of solid up-front design for each tier (UI, Biz Logic, Data Storage), by making it up as you go along and trying to convince yourself you can re-factor quickly.
I can't tell you how useful this front-to-back approach has been. Virtually all of the requirements and design unknowns have been squashed, and makes building the back-end a dream. Descreased risk, increased predictability, increased quality.
This approach definitely took more time upfront than a "document only" approach to design, but I believe the time saved later, and the risks mitigated make it an exceptional investment. I would highly recommend it to anyone.