Breaking the Horizontal Habit

The way in which software is developed varies from across the industry. Even among teams in the same organization, approaches are often different. Variety is a good thing, in that is gives software engineers new perspectives on their craft, helps colleagues work together to solve complex problems holistically, and encourages innovation in engineering.

In this article, I’ll discuss an approach to software development that helps teams delivery features quickly and drastically reduces complexity in the engineering process, the Thin Vertical Slice.

The Horizontal Approach to Web Software Development

Consider a piece of web software and the steps typically followed to build it across its layers. For those unfamiliar with web application development, most web software consists of three basic components: a user interface, a web API, and a database.

1. User Interface (UI): Contains all the UI components that users interact with, like buttons and forms. It also contains code for sending web requests to the API. This is commonly called the frontend of the application.

2. Web API: A separate application that accepts web requests from the frontend to perform CRUD (Create, Read, Update, Delete) operations in the database. It acts as an interface between the frontend and the database.

3. Database: Stores data about various models that compose the application and persists data across the application. Together, the web API and the database form the backend of the web application.

Step 1 Implement the entire database, including all the tables, stored procs, views, triggers, and schemas that are needed to support the app.

Step 2 Implement the entire web API, working through one “feature” at a time, including all the endpoints, data models, and supporting services required to interact with the database.

Step 3 Glue the Web API layer onto the Database layer, refactoring parts of each layer as issues in the “gluing” process arise.

Step 4 Implement the entire frontend of the application, including all the UI components, business logic, data models, and services required to talk to the Web API.

Step 5 Glue the User Interface layer onto the Database layer, refactoring parts of all three layers of the application as issues arise in the “gluing” process. Frequently cycle between Step 3 and Step 5, as needed.

In practice, teams often follow some variation of these steps, particularly when building web software that conforms to a traditional three-tier architecture. In this workflow, specialists often handle each layer: a frontend specialist, an API specialist, and a database specialist. In larger organizations, there may be a specialist team for each layer.

The project manager gathers requirements and works with developers to plan the work needed to reach the Minimum Viable Product (MVP) status. Developers then divide the work into each domain layer based on the requirements. Each layer is built up following the process outlined, with new layers being glued onto the previous ones. This requires heavy modification and refactoring to make the system function as a whole.

The Problem with the Horizontal Approach

The result is like a layered cake that’s been rushed, and reworked so many times it’s barely recognizable. Layers have been repeatedly removed and reattached, and parts may be unbaked, deformed, or destroyed. The project manager, upon review, is frustrated by the software’s inability to meet expectations and believes the team cannot execute effectively. Requirements are reworked, and the process starts again, with developers attempting to fix issues layer by layer. Everyone is stressed and productivity suffers.

This horizontal approach mirrors the pitfalls of the Waterfall model. Developers try to plan each layer perfectly to meet a rigid backlog of requirements. Once a layer is done, progress halts as they wait for approval from testers, project managers, and other developers. The rework required to glue together the layers often spirals out of control, making the system’s behavior unpredictable and slowing productivity.

A common variation involves working with a project manager to build an entire feature over 2-4 weeks. The team follows the same horizontal approach but claims to be "Agile" because they focus on a single feature. However, they still build the software layer by layer, resulting in hours of rework and no real agility.

A Vertical Approach: Thin Vertical Slice

The solution is to rotate this horizontal approach 90 degrees into a vertical position. Analyzing a feature vertically helps teams see the requirements needed to implement a piece of business functionality in its entirety, without getting bogged down in overlaps with other software parts.

This approach emphasizes focus, a critical concept for Agile development teams. By narrowing focus to an atomic piece of business functionality across the frontend and backend, teams eliminate non-essential work and reduce complexity.

Thin Vertical Slice is a strategy for software development that focuses on a narrow sub-feature meeting three criteria:

1. Focus: On an atomic piece of business functionality.

2. Isolation: Implementation is confined to the specific pieces needed for the sub-feature to work across each layer.

3. Ownership: One developer can own the work across all layers of the sub-feature.

Using the cake analogy, a thin vertical slice is like thin slice of cake that can be cut from the whole.

For instance, in an HRM (human resources management) software, a thin vertical slice of the vacation request feature could be a component to show the approval status of a vacation request:

• Add a component to the vacation request page with a green checkmark for approved vacations and a red ‘X’ for denied vacations.

• Add an API endpoint that returns the status of a vacation request.

• Associate a status with the vacation request data model in the database and modify the stored procedure to retrieve the model.

Even if the tool is not fully complete, it delivers on a basic piece of business functionality that can be expanded upon. Users can see approved vacation days on a calendar. It might look something like this.

Presenting this to stakeholders enables immediate feedback. For example, they might prefer airplane emojis to checkmarks or want vacation details to appear when clicking a calendar day. This feedback is invaluable and helps developers refine the application before expanding further.

Even though the tool is not complete, it delivers on a basic piece of business functionality that can be expanded upon as development continues. In this instance, a user views the calendar and can see a checkmark on their approved vacation days. The work was less complex, the feature is simple, and developers can approach changes in a more targeted way.

Why Horizontal Thinking Persists

Despite the productivity and complexity reduction of vertical development, many organizations still favor the horizontal approach. This is especially common in enterprise web application teams.

One reason is that developers often start their careers building small internal applications. The horizontal approach may work well for small projects, leading developers to apply it to larger, more complex applications where it fails.

Another reason is developers’ preference for following a plan. This is why Waterfall development persists despite its low success rate. Developers like knowing they can follow concrete steps to achieve a desired outcome. It seems logical to complete the database (the foundation) before moving to the web API layer. However, software development is complex, and the application’s foundation rarely interacts with other layers as initially envisioned.

Wrapping up

A Thin Vertical Slice approach to software development reduces engineering complexity associated with the knowledge work of software development. Requirements become hyper-focused on atomic business functionality that can be implemented quickly by developers. Equally important, room for flexibility in the development process means the team can address feedback quickly and confidently.

When building software from the nothing, there are some foundational pieces that might not fit into this vertical model. Choosing technologies, setting up systems and environments, and even putting together the shell of a frontend and backend system, are all required to move forward. These items are key and can’t be ignored, but they fall far outside the scope of what has been presented in this article and will have to be saved for a future discussion. Although, in general, setting aside these foundational pieces, I strongly encourage teams to start thinking vertically and outlining thin vertical slices for development as soon as reasonably possible.

If you or anyone you know wants to share their experience applying for jobs in the current job market, inside or outside software engineering, we encourage you to respond in an email to this newsletter! You may be featured in our next article.

Thank you for reading and we will see you in our next article as we continue our voyage.

Code on,
Matt, Editor and Software Engineer