If you ask a hundred developers to define software quality, you’ll probably get a hundred different answers. There are a lot of ways to categorize quality, but one that I find most useful is building the right product and building the product right.

Building the Right Product

First we have to make sure we are building the right product. The most performant and secure product, having the cleanest and most extensible architecture, covered with unit tests and acceptance tests is in vain if nobody uses it.

In their book, Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck define this dimension of quality as the perceived integrity of a product. Perceived (external) integrity means the totality of the product achieves a balance of function, usability, reliability, and economy that delights customers.

Traditionally, when customers want to build a product, they talk with business analysts and write down the requirements. These documents are then handed over to architects, who then define the high level architecture and pass the design documents down to programmers who start implementing. There’s a gap between each step and as we go through the process, we lose more and more information and our chances of building the right product get slimmer.

In Lean Enterprise: How High Performance Organizations Innovate at Scale the authors discuss the concept of friction between the expected outcome and reality, which leads to three gaps. There’s a knowledge gap between the outcome and the plan, since every time we work on a plan, we work with incomplete information and make assumptions (sometimes without validating them) and customers rarely know what they want until they see it. The more detailed the plan is, the bigger the knowledge gap will be.

Between plans and actions, there’s an alignment gap because plans can be misinterpreted or wrongly followed.

The last gap is between actions and outcomes and is known as the effects gap, because usually the actions that we take don’t have the effects that we have planned for.

So what is the answer to filling these gaps? Face to face communication, shorter feedback loops, transparency and empowered teams.

The rest of this blog post will highlight some of the ideas that I have seen put in practice as a means to achieve high perceived integrity. All of them have their roots in lean thinking and agile practices.

The Principle of Mission

“Therefore no plan of operations extends with any certainty beyond the first contact with the main hostile force.”

Helmuth von Moltke the Elder

The Principle of Mission Command is an army principle that is based on trust – superiors trust their subordinates that they can make the best decision with the information that they have. So, instead of giving detailed orders, they ensure that everybody shares the vision and knows the desired end goal. Superiors can rely on the ones closer to battle to make the right decision. The Principle of Mission comes as an alternative to the well known (and abused) command and control management style and applies well to IT. Workers in the IT industry are knowledge workers. For us to be efficient and productive, we need to believe in what we’re building, we need to be motivated and we need to be able to make decisions. There’s little motivation in following a detailed plan, that we know is wrong and won’t deliver the expected outcomes. That’s why it is important for every member of the team to know the purpose of the product, the strategic goals and the values that underpin it. Developers make day-to-day decisions and although each decision might seem insignificant, when you add them up, these could make or break your product.

I work for an outsourcing company, so we rarely know before hand the vision of our customers. That’s why I think the best way to start a new project is with a kick off workshop that brings together the business stakeholders and the build team. This is a good opportunity for the business to describe the vision and the expected outcomes of the product and to start building alignment. The build team should think about the target every time they make a decision to ensure that their actions are bringing everyone a (tiny) step closer to the end goal.

Since this is so important, it’s a good idea to have this knowledge available and easily accessible through information radiators and refresh it from time to time through workshops and presentations.

Short Feedback Loop

“If I had asked people what they wanted, they would have said faster horses.”

Although this quote is attributed to Henry Ford, he probably never said these words. Still, it is definitely easier to get feedback on something you see than to come up with a list of detailed requirements.

Agile Methodologies have been proven to be more successful in building the right product and many of the agile principles focus on customer satisfaction. In order to achieve high perceived integrity, we must show working software often to real business people, so we can get feedback and improve the product. This cannot be replaced by analysis, studies or market research, and it should be done as often as possible (in Scrum, this is done during the review at the end of each sprint).

This is getting even more important nowadays with movements like the Lean Startup which emphasize the importance of feedback from end users through the build-measure-learn cycle. Demoing to Product Owners every two weeks might not be enough if we release once every three months and end users are not satisfied. Of course, this depends on the line of business you’re in – in highly dynamic markets, a short time-to-market is crucial for the business’s success while for more stable markets this is less important.

Bottom line is that you need to get timely feedback whether you’re building the right product or not, and your delivery process should have built in feedback mechanisms.

Domain Knowledge

“The heart of software is its ability to solve domain-related problems for its user.”

Eric Evans

Many times requirements come in the form of workarounds – requirements shouldn’t talk about batch jobs and table columns. But in order to be able to spot these and provide the best solution, the build team must have domain knowledge. Gaining domain knowledge can be done by having direct access to business stakeholders. In outsourcing, this is harder to achieve, but that makes it even more important: the business must set aside some time for scheduled refinements, planning or ad-hoc queries.

Strategic Patterns of Domain Driven Design

Another important step that you can make in order to improve domain knowledge is to apply the strategic patterns of Domain-Driven Design (DDD).

Business people and technical people should talk the same language. This is known as the ubiquitous language and it binds the analysis (business) model to the code model. This makes sure that there is no information lost due to translating concepts between two different models.

Growing the language should be collaborative. On one hand, in order to explain the requirements, the business has to make implicit concepts explicit and give them names. On the other hand, the build team can get feedback from the code model and introduce new concepts into the vocabulary. For it to be a success, the ubiquitous language should be ubiquitous (duh!): it should be used in specifications, test names, namespaces, class names, methods, refinements and chats with the subject matter experts.

Another powerful pattern that you could apply is the Bounded Context pattern. If you’re working in a complex domain it might be a good idea not to use an enterprise wide domain model, but to split your model into bounded contexts. A bounded context protects the integrity of a model within a given business context and it explicitly defines its interaction with other bounded contexts.

If you get people from different departments (let’s say marketing, finance and inventory) and discuss a core concept of your business (product for example) you might see different opinions on what a product is. This is a sign that you should split your model in multiple bounded contexts. It makes sense to define what a product is and what are its attributes in each bounded context. This makes communication easier, since business rules should apply only within a given bounded context and you don’t need to bring in experts from four or five different parts of the organization when you only want to discuss the financial part of a product.

Specification by Example

“Traditionally, building the right product required big functional specifications, documentation, and long testing phases. Today, in the world of weekly software deliveries, this doesn’t work.”

Gojko Adzic

But what does work? How do you make sure that you’re building the right product? Have the customer write the specifications and then automate them. Even if you don’t automate them, if the requirements are written in a format that can be automated, they probably end up being more concise and explicit than otherwise. This is an excellent way to document your system and introduce a safety net that should catch regressions.

Ideally, the specifications should be written together with subject matter experts; it should be a collaborative effort. Unfortunately, in many cases, the business analysts, developers or testers write them, which means we lose some of the benefits of this approach. This being said, having the business read and agree on the specifications still provides a lot of value, since you can get their feedback and incorporate it in the specs. If the business doesn’t even care about the specs and doesn’t validate them, it means that they aren’t really sold on the idea of specification by examples and you run into the possibility of writing the wrong specifications, so you lose much of their value. In this case, it might not make sense to go through the hoops and spend a lot of time writing the specification in a business readable way (e.g. using the Gherkin format), when you could implement it in your favorite unit testing framework and be done with it. But, in this section, we’re talking about specifications that have been at least validated by business experts.

One of the main characteristics of a specification is explicitness: examples should remove ambiguity and are a great platform for communication. Concrete examples make anything easier to understand and provide the best documentation of what a system does (and not of what it should do).

In practice I have noticed that specifications are a good driver for communication. But, if you have limited time from the business, it’s probably better to use their time as efficient as possible. You can work with them to define key examples. Then, have the build team come with additional examples like corner cases or scenarios that they think might cause problems. Three Amigos (business analyst, tester and developer) Sessions are a good way of enriching a specification. Then, the business should validate all the scenarios. This is an effective way that we’ve used in practice to collaborate on designing the specifications.

Conclusion

So, to sum this up, to build the right product, you have to make sure that the entire team knows what the product should look like and what is its purpose. Business people should see working software often so that they can provide feedback and be sure that it suits their needs. In order to provide the best solutions, the build team must have domain knowledge and understand the problem domain. Having the technical people and business people working together on the specifications means that everybody knows what the system should do. If you then automate those specification, you ensure that the system does what you expect it to do.

These are just some of the methods that I’ve seen used in practice with the purpose of achieving high perceived product quality. If you want to find out more about these (and many, many others) have a look at these books:

• Lean Software Development: An Agile Toolkit by Mary Poppendieck and Tom Poppendieck
• Lean Enterprise: How High Performance Organizations Innovate at Scale by Jez Humble, Joanne Molesky, Barry O’Reilly
• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
• Patterns, Principles, and Practices of Domain-Driven Design by Scott Millett
• Specification by Example: How Successful Teams Deliver the Right Software by Gojko Adzic

Also, I’m interested in what other teams do to ensure that they are building the right product, so please share your ideas in the comments below.

In the next blog post, we’ll talk about some of the things that you can do to ensure that you are building the product right.