Why Software Quality Is Determined Before the First Line of Code Is Written

Talking about “software quality” conjures up a very technical image: testing strategies, modularity, architecture, refactoring… And it’s true: there’s often a lot to be done in these areas. But upstream, functional design also plays a crucial role. Many bugs encountered by users are actually design flaws, edge cases that weren’t anticipated. And even before that, what would be the point of developing an application to the highest standards if it were poorly designed, or, worse, failed to meet its users’ needs?

In my line of work, it’s impossible not to be interested in functional design: “Garbage in, garbage out.”

Functional design, the pivotal moment between Discovery and Delivery

What does “functional design” mean? Let’s start by situating it within the software development lifecycle:

Discovery: This involves identifying the problems users face and often digging deep to uncover the true need behind the stated request. Prioritizing these problems is then a strategic decision, as tackling one problem over another has significant implications for the company.
Design: Once the problem has been clearly defined, we can devise solutions, often organizational and software-related. The next step is to describe the expected behavior, that is, the application’s features, in a comprehensive and consistent manner. Some include this step in the Discovery phase, but I prefer to keep it separate.
Delivery: and finally, the actual implementation: development, testing, and deployment. I’ll skip over this quickly, as that’s not the focus today.

Functional design therefore consists of describing the what before thinking about the how. In other words, modeling your business as it would be if IT didn’t exist, and describing the expected behavior of the software (this is always part of the “what”).

So, to make things more concrete, here are a few tools, practices, and notations you could use during this stage. This is a non-exhaustive list.

Your Functional Design Toolkit

Personas: these are your typical users, whom you’ll give a nickname to foster empathy among your teams. In addition to their role or function, it’s important to clarify what motivates these people, the reasons that drive them to use your product or services, the context in which they do so, their level of computer literacy, and the frustrations they currently encounter with competing products and services. This work is therefore the culmination of a phase of qualitative and quantitative user research.
Processes/workflows: This involves describing how multiple actors interact with the system to achieve a common goal (such as approving an employee’s vacation request). This concept generally comes quite naturally to us, and you can rely on UML notation for a more systematic approach.
Modularity analysis: Modularization is an essential topic, as it determines the long-term evolvability of your IT systems; I’ve often discussed this. Don’t get me wrong; there’s nothing technical about this subject. It’s generally driven by “tech guys,” who rely on the heuristics of Domain-Driven Design, but defining the bounded contexts really depends on an analysis of your business. In other words, it’s a purely business topic, so much so that this modularity will often shape your product offering from the customer’s perspective.
Processes and modularity provide you with a broad, holistic view of the system you want to build. User Story Mapping (Jeff Patton) is a backlog management tool that preserves and builds upon this cross-functional view, but this time centered on the user and their User Journey. That’s precisely the problem with backlog management: when you organize tickets too rigidly, it’s easy to lose sight of the user, even if those tickets are supposed to be User Stories. It doesn’t matter to a manager whether they can log in using iris recognition if the application then doesn’t allow them to approve that vacation request.
Functional design is a subtle exercise that requires working in detail (“in-depth” exploration) without ever losing sight of the big picture (“broad” exploration, as we’ve just seen). Example Mapping (Matt Wynne) is, in my opinion, the ideal practice for drilling down to the finest level of detail (business rules, examples/tests), uncovering a whole host of edge cases, and realizing, once again, that the devil is in the details. This practice is what sets a truly great product apart from the run-of-the-mill offerings on the market. It’s worth noting that this exercise also feeds into the backlog: as we go into greater detail, it becomes clear that we won’t be able to implement everything at once…
Example Mapping comes with its own notation, but nothing prevents you from expanding upon it; the goal is for the various stakeholders around the table (PM, Dev, QA) to understand one another and explore the complexity of the subject as thoroughly as possible. With this in mind, you may want to establish a Conceptual Data Model (one per bounded context). The CDM, or “entity-relationship diagram,” brings out the domain concepts—sometimes implicit ones—and the relationships that connect them. This modeling is independent of any language paradigm, particularly object-oriented programming: the CDM is not a class diagram. It models the “what,” not the “how.”
Generally speaking, it’s up to you to find the right notation to be effective: sometimes these will be screen mockups (feel free to start with a simple sketch, ideal for letting your thoughts flow freely), sometimes UML sequence diagrams, state-transition diagrams to represent the operation of a finite-state machine, or even a matrix of application roles and permissions within the context of a role-based access control (RBAC) system.

Conclusion: “It’s technical”… really?

If these considerations seem “technical” to you, rest assured that we have discussed here only the application’s expected behavior, in other words, purely functional aspects. In any case, that word (“technical”) means nothing: I challenge anyone to offer me an unambiguous definition of it—someone should mention Heidegger to me right now 😉

Example: You’re designing a SaaS product consumed via an API (API First). Is specifying the signature of each endpoint a technical task?