Every year, thousands of large digital products never make it to production because of a gap in understanding between the technical people and the more business-minded people. Translating business requirements into technical requirements has a lot of room for error. And that room for error only grows larger when talking about back-end development - the least visible part of software engineering. In this post, we’ll not add to the confusion but try to explain a valid solution - one you can integrate into your business too.

The visible vs. the invisible

A digital product is roughly divided into two main areas: the frontend and the backend. 

As you know, the frontend deals with the visual part or everything the user interacts with. In essence: it’s visible. But that frontend translates these user interactions to back-end instructions - aka the “under the hood part”. Everything that makes a product work, but is not directly visible to the user. 

Now, our experience learned that it’s easier to talk with our clients about the frontend part - as it’s more straightforward and more tangible. But when the discussion switches to the back-end side of a product, things tend to get more complicated and sometimes even lost in translation. You risk misaligning your business goals with technical feasibility. But why?

Challenges in back-end development

The backend, which - roughly speaking - encompasses the API layer, data models and services of several systems, presents a different set of challenges. Next to that the infrastructure that hosts all of this, presents its own unique set of challenges. You can start to see why finding a shared language can become complex here.

Decisions made here operate behind the scenes, invisible to end-users and non-technical stakeholders. Yet, these decisions hold substantial implications for the product's future. Considerations like potential lock-ins with cloud providers are crucial for your product. Or features that improve the product’s maintainability or adaptability naturally shape your product’s future but don’t directly impact users. 

"Decisions made behind the scenes, invisible to end-users, hold substantial implications for the product's future."

Quality attributes as common ground

To ensure that the business aspirations and the technical execution are aligned, we rely on quality attributes as a starting point to define what can be defined as 'minimum', without risking a complete overhaul in the future. Yes, quality attributes are more than that, as you know by now. But quality attribute requirements also shape a shared language: a non-functional characteristic that all stakeholders understand and all technical people know how to implement.

A real-life example

Let’s look at a real-life example. In a recent project, we aimed for a Minimal Viable Product (MVP) release to deliver value as soon as possible and validate the product’s direction. To establish the “minimum” for this MVP, we first outlined the long-term quality attributes and then redefined the initial scope, so we wouldn’t risk jeopardising the long-term goals of this project. 

Together with our client, we shaped and prioritised our quality attributes to establish shared goals:

• Maintainability: Even though it was not strictly necessary for the initial release, we still opted for Infrastructure as Code (IaC). This ensured the product would be adaptable since it needed to be used across various engineering teams. Furthermore, it gave us the confidence to switch to a production environment when the time was right.
• Testability: Because we knew that we would keep building after the initial MVP release, we prioritised End-to-End testing from the get-go. This way, we ensured minimising the number of regression bugs, decreasing the time to detect them and having confidence in our growing code base.
• Performance: On the other hand, we recognised the limited user base of the product, so we adjusted our focus away from extensive performance optimisation.

Behind words like maintainability, testability and performance lie a bunch of technical decisions to make. The advantage of using these words is that we make the invisible visible again, especially for the client and its stakeholders. It’s no wonder that a CFO is not interested to invest in migrating from one technology to another. He might be convinced though if you tell him this sets the product up for handling peak loads of 1,000,000 users. 

"It’s no wonder that a CFO is not interested in investing to migrate from one technology to another. He might be convinced though if you tell him this sets the product up for handling peak loads of 1,000,000 users."

Creating a shared language

Ultimately, fostering a shared language in software development is key. Especially when we’re talking about the less visible back-end part of software development. And even more so when the technical expertise differs between everyone involved. 

At In The Pocket, quality attributes serve as our starting point to align our perspectives and ultimately foster a shared language to successfully build and deliver digital products, especially in an MVP phase. For some aspects, it will be straightforward to find this shared language. For other parts, it could prove to be difficult to find common ground. Nonetheless, these areas might prove to be ones where the impact on the product is biggest. So don’t tread lightly.