Building Software Teams

Preface

You can’t control what you can’t measure.

Tom DeMarco

Insufficient software quality is a problem of all times and in all industries. We at the Software Improvement Group (SIG) see this time and again in our daily work of source code measurement and code review. That is why we have chosen to share the lessons we have learned with a larger audience. In the companion to this book, Building Maintainable Software: Ten Guidelines for Future-Proof Code, we focused on the contributions made by each individual developer. In that book, we discussed ten guidelines that any practicing software developer should master to consistently write maintainable source code. Those guidelines are based on our experience that lack of software maintainability is largely caused by simple issues that occur over and over again. And thus the best way to improve maintainability is to address these simple issues.

But that is not enough. To fully benefit from those guidelines, developers also need to work as a team according to a shared process. That is the focus of this book. This book discusses ten best practices for getting the development process right such that software is produced of consistently high quality. Our best practices do not just point a development team in the right direction. They are accompanied with a set of metrics that helps the team to consistently execute and monitor them.

Getting software development practices right is essential. The right development process facilitates the team and each individual developer to perform at their best. Using these practices, we can avoid inefficiencies in development work. Think of the difficulties of reconciling inconsistencies between contributions (merge conflicts!), chasing nonreproducible bugs, manually rerunning tests, and everything else that distracts us from creating the best possible product.

The Topic of This Book

This book lays out ten best practices for facilitating a team of software developers and enabling them to develop high-quality code. Having high-quality code is a great asset: it means lower costs for testing and software maintenance, and faster delivery of functionality. Conversely, software that is insecure, unreliable, or difficult to maintain is a source of developer frustration, delays, and software defects.

The practices address shared ways of working in the team, together with the technologies they employ, the processes they have followed, and the work environment they share. Think, for instance, of using Continuous Integration together with its required technology (see Chapter 7). Another example is standardization of code style guidelines (see Chapter 9). The best practices in this book are well-known, and many programmers may have heard about them during their education or earlier experience. This book puts those best practices in an overall, lightweight approach to manage software quality. The best practices presented in the following chapters are independent of the choice of programming language and the type of software that is being built.

Why You Should Read This Book

Taken in isolation, each of the best practices in the following chapters are well-known. What is not so well-known, however, is which ones are most important and how to determine whether they are being done in the right way. That is what this book aims to do, setting it apart from other books on software best practices in two ways:

We have selected the ten most important best practices from experience

From our experience with advising software teams and managers, we know what works in software development and what does not. We also measure and benchmark software maintainability for hundreds of software systems each year, so the effects of specific practices such as Continuous Integration or test automation are very visible to us. We explain the most important best practices in a short and simple manner.

We explain how to measure success toward using these ten best practices

Knowing a best practice is only the first step toward getting it right. We provide ways to measure how effectively each practice is being applied, and thus to manage its consistent use.

Who Should Read This Book

This book is aimed at those involved in managing and steering the software development process. You may be a team lead, a senior developer, a software architect, or a leader of IT projects or software development (such as a Scrum Master). You may have management responsibilities of your own, or perhaps you are advising/reporting to management.

This book will help you and your team adopt our ten best practices for effectively producing high-quality software.

What You Need to Know to Read This Book

This book is the follow-up to Building Maintainable Software: Ten Guidelines for Future-Proof Code. We assume you are familiar with the concepts explained in that book, either from your own experience or because you have read it. Having development experience in a modern object-oriented programming language will certainly make it easier to read this book. But even if you do not have (recent) programming experience, you will be able to understand, apply, and benefit from our best practices.

Many of the best practices we discuss will be familiar to those who use Agile software development methods. Regardless of how much you know about Agile and how much you like it, the practices we present in this book will help you to produce high-quality software more consistently.

What This Book Is Not

This book fulfills a different role than existing process approaches such as Capability Maturity Model Integration (CMMI) and ISO 9001. Those approaches focus on what kinds of process activities are needed to gain a certain process maturity. They provide conceptual frameworks that are applicable to many contexts, defining what is important in general terms. However, they do not focus on software development and they do not provide development teams with immediately actionable guidance. This is what our best practices aim to do.

Process frameworks emphasize documentation and structure. They prescribe certain areas for which you need to design processes and document them, but they do not prescribe which way of working suits you best. This book reasons in another direction. We recommend best practices that can be incorporated directly in your own existing work processes. Our guidelines do not require the use of a formal process framework such as the ones listed earlier.

While this book does speak about the technology available for equipping a state-of-the-art development environment, this book is neither a recommendation for particular technologies, nor a hands-on user guide for them. In more concrete terms: we do discuss tools and technologies for version control, automated testing, Continuous Integration, static code analysis, and dependency management. While we may name specific tools, such as Jenkins, this book is not meant as an endorsement of any particular technology. It is also not a technical guide for the technology at hand. Instead, this book discusses the role the technology plays in today’s best practice software development.

About the Software Improvement Group (SIG)

The real author of this book is much more than just the one person mentioned on its cover. The real author is SIG, a software management consulting company. That is, the book consolidates the collective experience and knowledge of the SIG consultants that have been measuring software quality and advising about it since 2000. We run a unique, certified, software analysis laboratory that performs standardized inspections against the ISO 25010 international standard for software product quality.

Apart from assessing the quality of software products in our laboratory, SIG also assesses software development processes of our customers. We do so for two reasons. One is that it helps to put the outcome of a software product quality assessment in perspective. If the outcome of an assessment is lower than desired, this often can be explained by a process that impedes developing high-quality code. Or the other way around, if a team achieves high quality, is this because of or despite the environment in which they work? The best practices presented in this book are based on our experience in answering these types of questions.

SIG was established in 2000. Its roots can be traced back to the Dutch National Research Institute for Mathematics and Computer Science (Centrum voor Wiskunde en Informatica [CWI] in Dutch). After 16 years, we still keep and value our links with the academic software engineering research community. SIG consultants regularly contribute to scientific publications, and several PhD theses have been based on research to develop and improve the SIG quality models.

Related Books

For further elaboration on achieving high-quality software, we recommend several books in the field of software quality and development process measurement:

Building Maintainable Software: Ten Guidelines for Future-Proof Code by Joost Visser (O’Reilly)

The companion to the current book, written by the same authors. It focuses on 10 guidelines for developers to write maintainable software.

Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation by Jez Humble and David Farley (Addison-Wesley)

This book discusses development process best practices in detail with focus on Continuous Delivery principles.

Software Development Metrics by David Nicolette and Agile Metrics in Action by Christopher W.H. Davis (both from Manning Publications)

These books provide examples of using metrics in the software development process.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Note

This element signifies a general note.

Important

This element indicates an important remark

O’Reilly Safari

Note

Safari (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals.

Members have access to thousands of books, training videos, Learning Paths, interactive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.

For more information, please visit http://oreilly.com/safari.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway North
• Sebastopol, CA 95472
• 800-998-9938 (in the United States or Canada)
• 707-829-0515 (international or local)
• 707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/building_software_teams.

To comment or ask technical questions about this book, send email to [e-mail].

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

We would like to thank the following people for helping us to write this book:

• Yiannis Kanellopoulos (SIG), our project manager for overseeing everything

• Soerin Bipat (SIG) for his thorough review

• Ed Louwers (SIG) for his help with the visuals in this book

• All current and former SIG employees that are working and have worked on perfecting models for measuring, benchmarking, and interpreting software quality

We would also like to thank the following people at our publisher, O’Reilly:

• Nan Barber, our text reviewer

• Steve Suehring, our technical reviewer

• Holly Forsyth, our managing editor