Visualizing a product’s UI and code layers
by Ryan Singer (@rjs)
This article was originally published to Feltpresence.com in March 2011.
If I asked you to visualize a software product, a picture of the interface would probably come to mind. That’s natural because the interface is the product from a user’s point of view. But for us on the development side, products are more than just interfaces. They’re also the code, the connections between code and UI, the separations of concerns and the boundaries between features.
To visualize a product from the development side, I start with two layers: the code and the UI.
Depending on the product or the feature, the code and the UI can be in very different proportion to each other. On one extreme there are features that expose very little UI but require a lot of code. Think about a recommendations system for an e-commerce store. Hundreds of lines of code might analyze your buying patterns, the items you look at but don’t purchase, attributes across products and so on. But the only change in the UI is a simple list of products with a header that says “recommended for you.” Projects like this are icebergs: there’s a tiny bit of UI supported by a large amount of code. It’s also hard to draw correspondences between the code and the UI. Most of the code interfaces to other code, not the user.
On the other hand, there are many projects where the UI and the code layers are in balance. Take a typical CRUD-style web app for example, like a blogging tool. There is UI for creating posts, showing posts, editing posts. And behind each piece of UI is a small amount of code to write the post to the database, read and display the posts, update the records and so on. A lot of everyday business apps have this structure, and they basically look like layer cakes. Each piece of UI sits on top of a corresponding piece of supporting code.
It’s interesting to note that you can apply the distinction to whole products or to individual features. It helps me to have these pictures because they affect how I estimate the work. Icebergs are notoriously difficult to estimate. You have to really understand how the code is factored into different concerns in order to guess at how long each piece will take to build. Layer cakes are much easier because you can roughly estimate them by looking at the surface area of the UI.
These UI and code layers are a good starting point for seeing the product as a whole. A next step is to define scopes of work that cut across both layers. With a good picture of scopes we can try to visualize feature development as a step-by-step process. I’d like to address that in a future post.
