Something was wrong.
There was no trust within the organization. Their heavyweight software development processes got so much in the way they couldn’t really produce code anymore. The whole company was in a death spiral—their entire $750 million business was at stake.
You might have been one of the core developers on this team. Their core developers were brilliant, but they also had a second level of junior developers and offsite or second-site teams that were allowed to slip into an attitude of “code monkey-ness”—micro-focused on building “just this feature,” not thinking about how that single feature would integrate into the whole and unaware that some of the things they were doing were going to cause big problems in the short term and even bigger problems later on.
Even though the development effort was being led by very smart, experienced professional developers, the software that was being created didn’t follow good standards and wasn’t easy to work with. The whole development team didn’t understand the reasons behind the technical practices. They ended up cutting corners here or gaming the system there, creating little sub-teams—or even “teams of one”—operating with a different set of standards and an incomplete view of the whole system. This made integrating code a nightmare-like experience that no one looked forward to.
Or you might have been one of the managers responsible for getting this software done, shipped, and earning rather than costing money. Their managers were smart and experienced, too, and in the end just as frustrated, even demoralized, as the developers. This company’s managers saw deadlines slip, watched as unstable release candidates were passed into production, and try as they might they just didn’t know what to tell the developers to help them do things right. So management’s response was to add more process, which eroded even more trust, and deadlines slipped even more.
Too often, organizations can let the relationship between development, QA, and operations devolve into antagonism, which is what happened to this struggling company. Neither developers nor management understood exactly why they needed to step back and look at how they approached their work, but the reality of their burn-down rate made it clear that they had to.
I was the third consultant they hired, and the first not to address it as a “people issue.” What I saw was a legacy code issue. Their software was brittle and hard to work with. The company had grown by leaps and bounds over the past ten years and their code had suffered as a result.
The company had been trying to “go Agile” for years, but while many of their teams did institute some of the Agile practices, their existing code was constantly getting in the way, throwing off estimates and slowing them down. They knew they had to address both their existing legacy code as well as all those bad habits they’d accumulated along the way that got them into this situation.
We focused on the solid engineering practices we’ll cover in this book and why they work. And I wasn’t kidding when I said that the developers and managers alike were smart, experienced professionals. They listened, opening themselves to a collaborative process in which they were amenable to change. They put the necessary effort into fixing what was wrong with both their software and their processes.
If you were a software developer there, you would have noticed you were no longer getting calls at 3 a.m. because servers were down. You would have started getting fast, positive feedback from the tests you were adding that let you know your code was still working as you intended. With the rest of the team, you would have devoted 20% of your effort to cleaning up existing code and you would have seen that effort start to pay back in a big way—within just a year.
If you were part of the management team there you would have seen team members collaborate more effectively. You would have stopped being terrified of losing “critical resources” (individual developers) that could tank the company by deciding to get a job somewhere else, leaving no one else able to unravel that single developer’s code. You’d also see a shift in the team’s attitude as developers began to deal with the legacy code issue rather than pretending it didn’t exist.
It took several months, but as the quality of their code started to improve, so did the team’s velocity. The team’s estimates became more reliable and they began to consistently meet deadlines again without having to cut corners.
They started to break down walls, both literally and figuratively. Departments began to talk to each other. Working together, they restructured the way they did QA and the way they handled requirements. Testers sat with developers to figure out how to validate release candidates automatically. In time, they went from a largely manual two-week testing process to validate release candidates to a fully automated testing process that happened, in most cases, in less than two minutes. This saved them huge sums of money each year and gave them the foundation to transform their organization.
And the bottom line was: People began to care again.
This is a true story. I’ve seen it play out time and time again. And if you’re a software developer, or if you manage software developers, and fear you’re even now heading down this death spiral, this book will show you how to do what this company did to turn things around. If you’re struggling, you’re not alone.
Something’s wrong with the way most software is built and maintained. But it doesn’t have to be that way.