You can’t scale crappy code.

Code Quality Abstract

Code Quality is one of the four core values of SAFe.  For the enterprise that depends on software, attention to quality of code is as important as attention to any other engineering or business matter. The enterprise’s ability to deliver new functionality with the fastest sustainable lead time, its ability to successfully execute large development initiatives, innovate, and react to rapidly changing business environments – all depend on the endemic quality of the code. This article describes six specific, proven Agile software engineering practices that help Agile “Define-Build-Test” Teams assure systemic quality of code. In addition, the collaborative nature of these practices and a focus on frequent validation via fast feedback create an emergent culture wherein software engineering and software craftsmanship are key business enablers.

Details

Why The Focus on Code Quality in Such a Big Picture?

It should be self evident that endemic code quality is vital to any business that depends on software, but it becomes even more critical as the enterprise scales software development. There, the cumulative effect of even minor errors and wrong assumptions can create dire consequences at the system and enterprise level, with the potential for major, negative impact on customer deployments. So while much of the focus in SAFe is at the Program and Portfolio levels, and it is  fair to assume that good Agile Teams generally create high quality code, it is useful for SAFe to include and describe current Agile software engineering practices that help teams achieve the highest-level quality. In this article, we provide a summary of these practices, four of which: Agile Architecture,  Continuous Integration, Test-First and Refactoring, link to additional SAFe articles.

Business Benefits of Code Quality at Enterprise Scale

Of course, achieving high quality code is serious work that requires ongoing training and commitment, so before we begin, it is useful to consider some of the important business benefits that can be achieved when Agile teams and programs develop and deploy really high quality code.

  • Quality products and services. Low defect density software products and services provide higher levels of customer satisfaction, better returns on investment, and higher confidence for business partners.
  • Predictability and Integrity of the Software Development Organization. Without reliable control over system quality, it is impossible to plan new business functionality or understand development velocity. This creates a lack of trust with our internal business partners, and the potential negative pride of ownership on the part of the team, which is demotivating and wastes precious human capital.
  • Scalability. When the code clearly expresses design intent, exhibits simplicity, and has supporting integration and test infrastructure, adding more teams and functionality will result in more business value delivered. Otherwise, adding more developers and testers slows the enterprise down and creates unacceptably high variability in quality and release commitments.
  • Velocity, Agility, and System Performance. Higher code quality fosters better maintainability and enhances the ability to add new business functionality more quickly. It also enhances the teams ability to maintain and enhance critical nonfunctional requirements including performance, scalability, security and reliability.
  • Ability to Innovate. Innovation occurs in the confluence of smart, motivated people and the environment in which they operate. High code quality creates a fertile, technical environment where new ideas can be easily prototyped, tested and illustrated.

Six Agile Software Engineering Practices for Achieving High Quality Code

SAFe is built on a decade long evolution of better software engineering practices, driven in large part by the success of innovative Agile methods. When it comes to the code itself, Extreme Programming has led the way. In addition, the evolution of lighter weight modeling techniques, have provided a means of reasoning about really big systems in an Agile, and yet fully comprehensive manner. Together, we largely have what we need now, so it isn’t necessary to invent much of anything new, rather we just need to apply what we have learned in a systematic and disciplined manner.

In the following sections, we’ll describe a set of six comprehensive Agile software engineering practices (summarized in Figure 1), each of which contributes materially to the code quality of even the largest software systems.

Figure 1. Practices that support code quality

Four of these practices, Agile Architecture,  Continuous Integration, Test-First, and Refactoring, link to additional articles on SAFe, which provide more specific guidance to the teams doing this important work.

# 1 – Agile Architecture

Agile Architecture is a set of values and activities designed to support the active evolution of the design and architecture of a software system concurrently with the implementation of new business functionality. One element, Emergent Design provides the philosophical and technical basis for an incremental implementation approach and helps manage the complexity of increasingly large-scale solutions. At the same time, however, organizations must respond to new business challenges with large-scale architectural initiatives that require some intentionality and planning. Intentional Architecture provides guidance and technical governance to agile programs and teams. These activities create the Architectural Runway needed to enable teams to deliver business value faster and more reliably. SAFe’s Principles of Agile Architecture illustrates how collaboration, emergent design, intentional architecture, design simplicity, designing for testability, prototyping, domain modeling and decentralized innovation support this important underpinning to Agile development.

#2 – Continuous Integration

Continuous Integration is the software practice of merging the code from each developer’s workspace into a single main branch of code, multiple times per day. In that way, all developers on a program are constantly working with the latest versions of the code, and errors and assumptions between developers—and between teams—are discovered immediately. This helps avoid the risk of deferred system level integration issues and its impact on system quality and program predictability. Continuous Integration requires specialty infrastructure and tools, including build servers and automated test frameworks, but even more important is the cultural mandate: individuals and teams get credit only for integrated and tested software.

In SAFe, teams perform local integration at least daily, but equally important is the responsibility to integrate the full system, and run regression tests as necessary, to assure that the system is evolving in the intended manner. Initially, that may not be feasible every day, so an initial, reasonable goal may be to achieve full system level integration at least one or two times per sprint. You can learn more about this topic, particularly with respect to system level CI, in the companion article Continuous Integration.

# 3 – Test-First

“Test-First” is a philosophy of approach that encourages the teams to reason deeply about system behavior prior to implementing the code.  This increases the productivity of coding and improves fitness for use. It also creates a more comprehensive test strategy, whereby the understanding of system requirements is converted into a series of tests, typically prior to developing the code itself.

Test-first methods can be further divided into Test-Driven Development (TDD) and Acceptance-Test Driven Development (ATDD). Both are supported by Test Automation, which is required in support of Continuous Integration, team velocity, and development efficiency.

In Test-Driven Development, driven primarily from XP, developers write an automated unit test first, run the test to observe the failure, and then write the minimum code necessary to pass the test. Primarily Applicable  at the code method or unit (technical) level, this assures that a test actually exists and tends to prevent gold plating and feature creep of writing code that is more complex than necessary to meet the stated test case (which serves as a more persistent requirements proxy).

Acceptance Test-Driven Development (ATDD) is an advanced discipline whereby the criteria for acceptable system behavior, as specified by the Product Owner, is converted to an automated acceptance test that can be run repeatedly to assure continued system conformance as the system evolves. ATDD helps keep the team focused on necessary system level—and customer observable—behavior, and gives the teams a clear success criteria target.

#4  – Refactoring.

Refactoring is a “disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior” [Ref 4]. As Agile eschews “Big Up Front Design” (BUFD), and “welcomes changing requirements, even late in development” [Ref 5], this implies that the current code base is either resilient or amenable to change as new business functionality is required. In order to maintain this resiliency, teams continuously refactor code in a series of small steps to provide a solid foundation for future development. Refactoring is a key enabler of emergent design and is a necessary and integral part of Agile. Neglecting refactoring in favor of “always new functionality” will quickly create a system that is rigid and non-maintainable, and eventually drives increasingly poor economic outcomes.

In other words, refactoring is not optional, and you can learn more about SAFe’s perspective on refactoring here:

#5  – Pair Work

Pair Programming involves two programmers working at single workstation. One codes, while the other reviews, reflects, inspects and adds value to the coding process. Then the roles are switched. Pair programming is integral to XP, but it is also a  controversial aspect. Perhaps it one of the reasons  XP—and even more importantly, all its related, excellent software engineering practices—does not have as much momentum in the marketplace today as many of us have hoped. (Perhaps SAFe can help drive a resurgence?)

We take a broader view of pairing in SAFe and prefer the label pair work, whereby team members work together in a variety of pairing aspects to peer review each others work, while providing for explicit and programmatic knowledge sharing. Pair work, and the communication and interaction required, is absolutely essential in achieving high quality of code. Pair work is also a great foundation for refactoring, CI, test automation and collective ownership.

In practice, we see a number of different styles of pair work in Agile teams, each has value on its own, and many can be used in combination. Some teams follow pair programming standards for all code development as prescribed by XP. Others pair developers and testers on a user story; each reviews the other’s work as a story moves to completion. Still others prefer more spontaneous pairing where developers pair for critical code segments, refactoring of legacy code, development of interface definition, and system-level integration challenges.

Simply put, two eyes are indeed far better than one, especially when it comes to building large, complex, and necessarily-highly reliable systems out of really small pieces!

#6 – Collective Ownership.

“Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes.”[Ref 6]. Collective ownership is particularly critical in SAFe, as big systems have really large code bases, and it’s unlikely that the original code developer is on the team or program. Even when that person is on the team, waiting for one individual to make a change is a handoff, and certain delay.

Implementing collective ownership at scale requires following proven, agreed-to coding standards across the program, embracing simplicity in design, applying intent-revealing code constructs and building interfaces that are resilient to changing system behaviors. Active and purposeful knowledge sharing by constant interaction within teams (pair work, individual rotation), and across teams (CI, Communities of Practice) is also part of the solution. Collective ownership also includes collective test ownership, as individuals working even in a narrow area of the code can break someone else’s tests, and one cannot wait for someone else to fix the test or underlying code. Strict standards for test code, tests written in natural language (tools like FIT, Cucumber, Robot Framework support this) and constant attention to health of the test suites are also critical.

Summary

In this article, we’ve described the benefits and effective practices of assuring endemic code quality while building big systems in a Lean and Agile manner. Code quality requires attention to detail and a commitment to technical excellence on the part of all individuals, teams and programs. It also requires active support of our Lean-Agile Leaders, who understand that critical business benefits cannot otherwise be achieved. But code quality is not just a set of software engineering practices, it is also a culture of collaboration, professional discipline and software craftsmanship, visibility, frequent integration and validation of assumptions, and continuous refactoring to enable faster value delivery to the business.


Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley, 2011.

[2] Shalloway, Alan, et al. Essential Skills for the Agile Developer: A Guide to Better Programming and Design. Addison-Wesley, 2011.

[3] Beck, Kent, Cynthia Andres. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2004.

[4] Fowler, Martin. Refactoring.com

[5] Agilemanifesto.org

[6] http://www.extremeprogramming.org/rules/collective.html

Last update 1 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.