I’ve heard a lot of people say that because they are using Agile or Scrum that they don’t need to do design or write documentation—or even think. Nothing is further from the truth!
I wrote a post about this in 2011. I called it “The Scrum Excuse” at https://tobeagile.com/2011/06/28/the-scrum-excuse/.
Agile software development was created by people like Bob Martin, Kent Beck, Ward Cunningham, and Ron Jefferies. I know many of these people and I can tell you they are highly disciplined individuals and highly skilled software developers.
CMMI, Waterfall, RUP, Six Sigma, etc. have so many checks and balances in them to try to assure quality that developers spend all their time “doing the process” and end up having little time to actually put quality into their product. Agile was a reaction against heavyweight processes so developers had more time to focus on developing. But just because there isn’t as much process in Agile doesn’t mean that it was intended to be undisciplined. Let’s face it, writing code without any idea of a design is not only negligent, it’s also pretty stupid.
Those original authors of the Agile Manifesto always focused on code quality so they probably assumed that a focus on quality was obvious. To many developers I meet these days, focusing on code quality isn’t obvious. Without a disciplined focus on code quality as well as following key developer practices, the code written on an Agile project can quickly degrade into a maintenance nightmare.
On real Agile projects, I wouldn’t say the design phase is nearly non-existent. On the contrary, we practice emergent design where we design as we go throughout the whole project. This is not a paper design that lives in our imaginations but rather a real design in working code.
Emergent design is an advanced technique that’s a bit hard to explain if you haven’t done it before but it’s definitely a discipline and developers can be much more productive with it because it better leverages our skills and tools for creating code.
As an experienced Agile developer, I can tell you that I definitely do upfront design. But for me it happens in a matter of milliseconds. I’m so familiar with design patterns that the moment I hear a problem statement I know exactly what patterns will help. I also have a series of practices that let me encapsulate issues that I don’t know how to deal with now so I can deal with them later and not need a lot of rework. These techniques are not taught in schools and not generally known among developers but I find them critical to successful software development with Agile.
I’ve written a lot on these topics over the years. You’ll find tons of tips and tricks described on my blog. This year is the tenth anniversary of my blog. I encourage you to check out the hundreds of posts at http://ToBeAgile.com/blog. I also published a book on this very topic called Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, which you can learn more about at http://BeyondLegacyCode.com.
Writing software is one of the most complex activities that humans can engage in and because software is so fundamentally different than everything else in our world, building it properly isn’t always obvious. We’re a young field and we have to come together to share best practices and raise the level of professionalism across our industry. That’s my mission. I hope my materials are helpful to you. Visit my YouTube channel, @ThePassionateProgrammer (https://m.youtube.com/channel/UClNB39bdGrUE9dEOtm8J8ZQ), to learn more.
