It has been several years since I became convinced that the only reasonable approach to development is "top-down/bottom-up", or "top-down design, bottom-up development." More to the point, I assumed that the rest of the world was on the same page.
As it turns out, there is still considerable debate on the subject. Even within our Engineering team at AdvancedMD, we occasionally see examples of database-driven UI design, instead of UI-driven database design.
As I've studied the issue, I've discovered that the terms "top-down" and "bottom-up" mean different things to different people. In fact, my definitions are probably completely wrong, if this wikipedia article is accurate. For the purposes of this article, though, here's what they mean to me:
Top-down: This could also be termed "front-to-back", I suppose. It means that the UI design is fleshed out, prototyped (in the ideal case), and reviewed by stakeholders before any work begins on the middle and database tiers.
Very closely related to top-down design is the notion of UI-First Software Development, as described ably (although certainly not as a totally original thought) by Jeff Atwood. As Jeff states, "...the user interface is the application."
A variation of top-down development is top-down/bottom-up development. In this approach, the feature or application is designed from the front to the back, but then the actual development (schema and code that are ready to check in to the build) is done from the database forward.
Bottom-up: In the bottom-up approach, the UI may be described, or even roughly illustrated in a screen shot, but design begins at the database, based on the developer's understanding of what the purpose of the feature is. Or perhaps the middle tier class architecture and database design are built roughly simultaneously.
(I'm using the term "UI" loosely for this discussion. In fact, the UI could be an API interface, or XML contract, if the feature has no visible UI.)
The strongest argument for bottom-up design: It's where most developers (particularly those who started out their careers in database development) feel most comfortable. Think about it: What would you rather do, work with end users and business analysts to design a usable UI that meets complex business requirements, or build a properly normalized relational database schema? Most developers would find the latter far more enjoyable.
Also, if you're lucky, you have application designers on your team who are responsible for the aesthetics of your software. It's much easier to leave that aspect of software development to someone else...after you've build a solid framework to support the facade.
So, why would a developer choose to migrate from a bottom-up approach to top-down?
Simply stated: Far less rework is required if the UI is fully understood and reviewed by stakeholders before development begins in earnest.
It's a fact of life that it is nearly impossible for stakeholders to fully understand the implications of UI design decisions without being able to see the UI. And it's very difficult for them to anticipate show-stopping flaws in the UI design without seeing a prototype within the context of the application as a whole.
Here's a typical sequence of events for a simple project using a bottom-up approach (with creative input from my 10 year-old son):
So, how is a top-down approach different? Phases 1 and 2 are essentially the same. No matter how you tackle a project, the stakeholder is going to express her idea in ambiguous terms, but the developer is going think that he understands, when in fact they are speaking different languages.
The key is in phases 3 and 4. Instead of spending days or weeks building a product that he doesn't understand, the developer creates a screenshot that illustrates his understanding of the stakeholder's idea. When the stakeholder sees the screenshot, she immediately realizes that, while she envisioned two concentric circles, the developer understood two adjacent circles of the same size.
Then the developer creates a prototype of the square with two concentric circles. The result is exactly what the stakeholder originally envisioned, but the prototype allows her to see the square and circles actually working together. She realizes that the inner circle really needs to be a triangle. The developer refactors the feature accordingly, and the stakeholder certifies that the design meets the business needs of the customer.
Finally, the developer builds the feature, in roughly the same amount of time that he would have spent in the bottom-up approach. In all likelihood, some tweaking will be required, but no major rework will need to be done.
Clearly, there are environments where a bottom-up approach will give you better, faster results. Perhaps that's the case when the data is the application. But that's certainly not the case at AdvancedMD, where usability and efficient workflow are key to our success. I would imagine that most other HIT software vendors are in the same boat.
As I've written this post, it has occurred to me that one of my other favorite development patterns, "the walking skeleton", is extremely well-suited for top-down development. Or, perhaps top-down development is well-suited for walking skeletons.
They also share a potential hazard: As soon as you show a customer or other stakeholder a "working" prototype, they may see the feature or product as "nearly done" and become impatient when the final product takes 5 or 10 or 100 times as long to build as the prototype.
In any case, I'll be writing about that combination later.
No comments:
Post a Comment