Building Software Teams

Chapter 1. Introduction

Experience is the name everyone gives to their mistakes.

Oscar Wilde

Imagine you lived a century and a half ago, and you needed a car. Nothing fancy, just something for the occasional family visit. Obviously, it would be the variant that needs a horse in front of it, and it would be called a “carriage.” Given a period in the mid-1800s in which carriage-making was not yet standard practice, your only option would be the local blacksmith. Carriage making was a craft, not an industrial process, with a unique result each time (so not with a fully predictable result). In addition, carriages were very expensive relative to disposable income: few people could afford their own carriage.

Fast-forward to 2016. Even if your town still features an artisanal blacksmith, that is not where you get your car(riage). Except for very special hobby cases, cars are manufactured by the tens of thousands on assembly lines, in an industrial process. This process is so predictable that two cars of the same model and color can only be distinguished by their license plates. Relative to disposable income, they also became a lot cheaper.

This predictability is a result of a mature industry, in which processes are standardized and highly automated. Of course, a comparison with software only goes so far. You do not need to build identical copies of the same software system for different users and the functionality of a car is fixed during the manufacturing process, while software needs to keep changing. But just as each car that comes off the production line must offer the same reliability, performance, safety, and comfort, so must each new version of a software system provide the same reliability, performance, security, and usability.

And consider what the experience of the car industry has done for its quality and process: designing components with computer simulation models, in a way that they are backward compatible—replaceable—with other versions of the car brand. Testing them individually before integrating them into the product. Testing overall car design in simulated environments, measuring and predicting effects of changes on the road. Doing crash tests, volatility tests, endurance tests. Following a structured process for checking and testing scenarios.

Software development can benefit a lot from these best practices in terms of predictability. For instance, process standardization, automation of the production line, and test automation and simulation. Also, the principle still holds for software that quality cannot simply be added after the product is finished. A bad design or chaotic implementation cannot simply be turned around. In a car assembly line this is evident, but from experience we know that this is just as applicable for software.

In this chapter, we first present the big picture: our view on software development and the role that the best practices of this book play in it. We discuss software development as a process in the following section, followed by software quality and ISO/IEC 25010, then the ISO standard that defines key software quality concepts. After that, we introduce the so-called Goal-Question-Metric (GQM) approach as a practical, lightweight way to control software development. Finally, we present a preview of the practices that are discussed in the subsequent chapters.

Software Development as an Observable Process

At the beginning of this chapter, we argued that software should be developed in a controlled process. This means that we can view software development as a process in the first place. In order to arrive at output (working software), organizations clearly need resources (developers, tools). Developers receive inputs such as requirements and change requests, and work on code within the constraints and controls of the organization (time, budget, quality goals).

The best practices presented in this book are about controlling this process. Controlling in this context means ensuring that working software is delivered that meets the requirements and quality goals, within a reasonable time and budget. To control is a verb, and rightfully so: in this book, we view process control as a continuous activity. To control software development, we need to observe its characteristics: output, input, resources, and controls. This observing and controlling asks for an active organizational role.

So what are concrete observations and control actions in software development, and how does this connect to the best practices that we discuss?

First, the observations. Software development is suited for measured observations. You may think of the following:

• How large is the backlog?

• How many issues have been resolved (over a given amount of time)?

• Which part of the codebase is covered by automated tests?

• What is the performance efficiency of the software delivered (e.g., as measured by transactions per second or number of possible concurrent users)?

• How much of the budget has already been spent?

• How many of the developers have passed a formal certification such as the Oracle Certification Program?

You can see that there is a lot that can be measured in software development. In fact, we believe that anything can be measured. But that does not mean that everything should be measured. This is exactly why we introduce GQM in “The Goal-Question-Metric Approach”, because this approach helps the controlling party (e.g., a development lead) to choose the best metrics, given specific goals.

Consider that measurements are only effective if they help you control something. Requirements, change requests, and time and budget constraints are typically not under the direct control of the development team or its lead. However, developers are in control of the way that development best practices are applied. You may think of control actions such as the following:

• Bring test automation to a higher level.

• Start using a third-party authentication framework.

• Introduce a tool for Continuous Integration.

• Change or improve staff skills by training.

Note

With “process control,” we are referring to measures that facilitate development and prevent issues. Resolving issues after software delivery is not a type of process control, but rather damage control.

Software Quality According to the ISO 25010 Standard

This book is about best practices for achieving high-quality software. We are using the ISO 25010 standard as a framework for understanding what makes software high quality.¹ This section discusses how ISO 25010 defines software quality and how we use and interpret this in this book.

Software Product Quality in ISO 25010

Up to a certain point, quality is something subjective and undefinable. Luckily, ISO 25010 makes a distinction between experienced (subjective) quality and inherent (product) quality. In ISO 25010 these are defined and separated as two models, called the quality in use model and the software product quality model.

The term quality in use refers to the impact a software system has on its stakeholders or users. The same system may have different quality in use for different people, depending on their wishes and behavior. This is subjective quality: it depends on who judges it.

We focus on the software product quality model. It deals with software quality characteristics that are inherent to a software system and can be assessed in production. The eight defined characteristics of software product quality are: maintainability, functional suitability, performance efficiency, compatibility, usability, reliability, security, and portability.

These eight characteristics are independent of users and context. That is a good starting point for assessing quality in a reasonably objective manner. For example, source code can be analyzed for security flaws or impediments to performance. And indeed, security weaknesses and performance issues are well suited for source code analysis. Note that it is dependent on the way the system is deployed, whether such findings manifest themselves in production.

The Contribution of Each Developer Matters

From experience we know that the contribution of each developer counts for achieving high-quality software. Following these best practices requires consistency and discipline from each team member. It is not just the most senior developers who are responsible for delivering quality software. And it is not only the junior programmers who should stick to the rules.

It also requires setting the right example, in order to avoid the “broken windows effect” where people break the rules and others follow. For example, when one developer takes shortcuts in terms of quality, other developers tend to copy that behavior. Setting the right example is not necessarily about being the most skilled engineer, but more about retaining discipline during development.

Developers can be greatly facilitated to retain that discipline. For example, establish a consistent development process in which technical steps are largely automated or define standards for using third-party code. Also, having metrics makes behavior transparent, such that a team can hold each other accountable for shared responsibilities.

Measuring and Benchmarking Development Process Maturity

As mentioned in the Preface, we (at SIG) measure both the software products and the software development process of hundreds of software teams each year. To measure the software product, code quality is rated against our Maintainability model. The thresholds for various metrics in the model are derived from code measurement data that we collected over the years.

Similarly, to measure software development processes, we check the activities of a team against a standard set of best practices. We call this a Development Process Assessment (DPA). Over the years, we have learned which best practices are most important and from the collected data we have been able to assign simple maturity levels to each practice. We categorize each practice as “basic,” “intermediate,” or “advanced,” depending on how difficult it is to apply. That categorization is based on our data of how clients have adopted those practices.

The chapters of this book are a reflection of what we have learned to be most important to the working developer. At the end of each chapter, starting at Chapter 3, we provide results of our DPA benchmark. We relate each of the practices to the total benchmark and explain why certain practices are more difficult to implement than others.

The Goal-Question-Metric Approach

GQM serves as the linking pin between the practices: we present them as a combination of goals, questions, and metrics. We believe that anything can be measured. But that does not mean that everything should be measured. Measurements do help in identifying problems and monitoring the progress when working to correct them. Identifying the right metrics begins with asking the right questions. That is why the Goal-Question-Metric (or GQM)² approach takes a central position in this book. We experience in practice that it is essential to be able to apply GQM’s reasoning to make use of the right metrics. It is common to measure too few, too many, or irrelevant things and that is frustrating rather than revealing.

Defining the right measurements is not easy. Also, measurements can be misunderstood or used for the wrong purposes. This is why we devote the next chapter to the topic of how the GQM approach can help a team and a team leader with defining the right metrics to achieve high-quality software.

An Overview of the Development Best Practices in This Book

In the following chapters, the best practices are presented one by one. The order of the chapters signifies a level of “maturity” of those practices: from development prerequisites to “mature” ideals in software development.

Here is a brief overview of the outline we will follow:

Derive Metrics from Your Measurement Goals (Chapter 2)

Apply Goal-Question-Metric to choose metrics that help you control your development process.

Make Definition of Done Explicit (Chapter 3)

Define a specific Definition of Done to be able to tell how far away you are from your goals and to know when you are done.

Control Code Versions and Development Branches (Chapter 4)

Use a version control system to control and merge different development tracks.

Control Development, Test, Acceptance, and Production Environments (Chapter 5)

Take control over your Development, Test, Acceptance, and Production environments to achieve higher consistency in the way your software flows through the development pipeline.

Automate Tests (Chapter 6)

Automated tests enable near-instantaneous feedback on the effectiveness of modifications. Manual tests, in which you provide some input and then observe the output and behavior of the system, do not scale.

Use Continuous Integration (Chapter 7)

Writing tests and automating the build/test cycle makes developers’ work easier and repeatable. Combined with automated testing, you have more confidence in the actual behavior of the system.

Automate Deployment (Chapter 8)

Automate the process of pushing versions into production. This involves automation of tests and deployment steps, which gives more confidence when pushing into production, or rolling back when something goes wrong.

Standardize the Development Environment (Chapter 9)

Standardize the development environment, because it relieves developers from having to manage manual configurations and makes the behavior of your software more predictable.

Manage Usage of Third-Party Code (Chapter 10)

Reusing software written by others avoids reinventing the wheel, but needs to be managed.

Document Just Enough (Chapter 11)

The main things you need to document are nonfunctional requirements, high-level design decisions, and your Definition of Done. Documentation needs to be current, concise, and retrievable.

¹ International Organization for Standardization, “Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models”, 2011-03-01.

² The GQM approach is described in: Victor R. Basili, Gianluigi Caldiera, H. Dieter Rombach, “The Goal Question Metric Approach,” in Encyclopedia of Software Engineering, Wiley, 1994.