Integration is one of the most painful parts of a traditional software development process. After the system is designed and coded it gets integrated together in a Waterfall process, and this is when the nastiest bugs show their faces. It’s also when we really can’t afford to address fundamental issues.
When I was doing Waterfall development throughout the 80s and 90s, life was good for the first nine months of our annual development cycle, but in the last three months, which were devoted to integration and testing, I aged far more than a year. When I was in it I recognized that this was not the way to build an industry and keep it sustainable. People burned out, but then the next project would come along and things would be great for the first nine months.
Building to a release rather than to a feature is not the way to construct virtual things. Software is fundamentally different than practically everything else in our world and if we want to be able to build it effectively we have to begin to understand its unique nature.
Instead of putting off integration, what if we were to integrate all the time, as we go, whenever we have any little bit of functionality? If we do that then the big pain of doing a giant integration goes away. We may instead have lots of little integrations to do throughout the day, but they’re so small, and the changes we made are still fresh in our heads, that they’re relatively trivial to fix if something isn’t working.
In fact, integrating code as it’s being built is one of the most valuable forms of feedback a developer can have. If we’re told about a bug days, weeks, or even months after it’s written, it takes a lot of time and energy to re-familiarize ourselves with the code, find the bug, figure out what the right thing to do is, and fix it.
Building software incrementally means that we are going back into the code we wrote in the previous iteration to enhance and add features. If the code we wrote is difficult to work with we’ll suffer. So instead, developers doing Agile pay attention to making their code easier to work with for a really practical reason: They’ll have to work with it in the future. This is one of the main benefits of Agile that isn’t often talked about.
Feedback is critical for building anything but especially for building software, which cannot be touched or tasted or seen. Software is intangible, it’s the most opaque thing that we deal with as human beings, yet our process for constructing it contains very few checks and balances. This is not true in physical construction where there’s all sorts of testing and verification that goes into building a bridge or a shopping mall or an engine—but the way we build software is different.
We start with this specification that kind of sort of almost describes how a system should behave. That specification typically comes right out of our minds, from our imagination, what we can visualize we want. Then a developer takes those specifications and writes code around it based upon the ideas in their minds that they got from reading the specifications. And then they deliver the code.
No checks, no balances. Sometimes there is a QA process that tries to hunt for bugs or usability issues, but even that process is rarely formalized. And since it’s impossible to assure that there are no bugs in even a relatively trivial program all testing can do is find common problems that the tester thinks to look for.
We need checks and balances that make sense, that support us in moving forward with good code, and I believe that many of the methodologies in extreme programming do just that.
But the thing about extreme programming that a lot of people don’t understand is its context. The developers who came up with extreme programming are highly disciplined, and to do extreme programming successfully requires paying attention to good quality in software, following principles and practices, and being highly disciplined about it.
I hear from so many new Agile teams that they feel they shouldn’t have to do any upfront design because they’re doing Agile—and this is just a major misinterpretation of what it means to do Agile.
It’s true that in Agile, we don’t do a lot of upfront design, but that’s because we’re doing design throughout the entire development process, not just upfront like we did in a Waterfall process. We’re emerging designs as we go and that requires a great deal of discipline and paying attention to our code and the designs we’re working with. If we don’t pay attention to these things we’ll end up just making a mess.
I liken Agile practices to power tools. You can cut more wood with the chainsaw than you can with a handsaw, so chainsaws are valuable. But they’re also much more dangerous than a handsaw. Agile includes some very powerful methodologies but as Spiderman’s uncle said, “with great power comes great responsibility,” and it’s our responsibility if we’re following an Agile process to be disciplined about it especially since we all have the checks and balances that Waterfall tries to impose to assure that we are creating quality software.
Just because you’re “doing Agile” doesn’t assure that you’ll be successful. We can’t just blindly follow the practices. While many processes in life can work if you just follow them without understanding why, this isn’t true with Agile practices and processes. We must understand them and constantly stay alert for how it’s working. It’s not enough to just get feedback, we have to do something with that feedback. We have to learn from it, and if we do we can be successful.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
