Bottom-up vs. top-down tech design

Nearly 25 years ago, when I was an intern at a capital markets trading systems company (later acquired by the London Stock Exchange), the requirements for my first project came to me not in the form of a Word document, a flow chart or even a UI wireframe. It came in the form of a fully fledged ER diagram (i.e. a complete relational model of the domain). The project was to develop an issue tracker (Jira didn't exist back then, and products available at the time weren't up to the task).

The diagram defined, amongst other things, the tables and columns required for holding all domain entities, the data types of all their attributes, their constraints and the foreign key relationships, e.g. issues, issue_comments, users, permissions, roles, role_permissions, user_roles, issue_statuses, issue_state_machine etc. Beyond this, I was only given a brief verbal explanation of how the issue tracker should look like. But even as an undergraduate, this was enough for me (with some help from a senior engineer, of course) to design and develop a business logic layer (using Servlets) on top of the database (which was Oracle), and then a UI layer (using JSP) on top of that.

This is an example of a bottom-up design. It starts from the lowest layer of the system architecture, which is the database, and builds up, much like how a construction project starts with a blueprint/plan.

But more recently, I have been taking the opposite design approach: design the UI first, assuming the existence of any API endpoints needed; then design those endpoints, assuming the necessary schema exists; then finally construct the database schema that fulfills the needs of those endpoints. This has worked unusually well for both me and my teams: not only is it a structured, step-by-step way to perform technical design which does not always require a genius level engineer, once documented, the design naturally tells the story of why each design element (an API, a column etc.) was introduced.

By contrast, the bottom-up approach requires significant brainpower: it requires complete knowledge of the domain and its entities, and a mind that can visualize the end system while designing the schema. In fact, the database schema I received was done by just such a person -- a rare commodity that not all teams posses.

Which way is better? It depends.

If your business domain and the problem is very well-understood, and you are under pressure to get the product right the first time, then it makes sense to start bottom up: define the full data schema, design the business logic layer on top if it, and then the UI layer on top of that.

If you're in a more iterative environment, where you are forced to discover the requirements as you go, and speed of delivery is more important than getting things right the first time (in other words, a startup environment), you are better off with the top-down approach.

Here is one method of doing top-down technical design: vertical slicing.