Are you humming in your head Paul Simon’s “Still Crazy After All These Years”? I am. And it does seem crazy. Crazy that some ideas that came out over 20 years ago in the fast-paced software industry are still relevant and valuable today. But they are.
Kent, Ron, Ward, and many others who were early innovators of Extreme Programming (XP) really nailed it. XP was the basis for Agile software development. It is a set of technical practices for incrementally building software and that’s how Agile started. Agile and Scrum have applications beyond the world of software and understanding its roots can give us greater insights on how to use it universally.
I personally believe that the technical practices of XP are where the real treasures lie. Practices like refactoring and test-first development, which sound complicated initially but when you boil them down to common sense, reveal wholly different ways of approaching problems that have vast value and utility both for developing software and for just thinking clearly.
The practices that XP discovered for building extensible code incrementally can be useful in many other domains because what we are really talking about are mental tools and techniques that help us think and model our understanding more clearly. This has obvious benefits in software development but thinking and modeling are things that we do all the time, and so these same tools can be applied in many other areas and disciplines.
Our goal in software is to build models that allow us to go back later and extend them because in reality, that’s what we need to do with software. The only software that doesn’t need to change is the software that is never used. If people use software, then invariably they will want it to change because they will see better ways of doing things. This is good. We want to encourage this in the industry because that’s how we improve.
Traditionally in Waterfall software development, we have resisted change because we had the notion that is more beneficial and efficient to build in batches. This is true in the physical world but not in the virtual world. Building software in batches is shockingly inefficient. We want to find ways of removing barriers to change when building software so we can “welcome changing requirements, even late in the development cycle,” as the Agile Manifesto says.
Extreme Programming includes several critical and fundamental practices to allow us to build software that is more understandable and extensible so code is more straightforward to change. Many of these ideas are actually not foreign to us but we haven’t really thought of applying them to software.
For example, triangulation is a technique that has been used from the early days of maritime navigation to modern-day GPS devices and it represents a fundamental way of achieving clarity. If your reference is only a single point on the horizon it may be difficult to plot an accurate course at sea but if you have multiple points that you can triangulate from then you can establish a much more accurate course heading. This was true for early maritime navigation and is also true in today’s GPS satellite networks. If your GPS device has only two satellites that it’s receiving pings from then you’ll get a rough estimate of where you are but the more satellites that it can triangulate from the more accurate the location will become.
This is also true in thought. We talk about it as gaining perspective and really the very definition of understanding is being able to see from multiple perspectives or points of view. This is exactly what test-first development does. It gives us the ability to see the services that we build from an outside perspective. All too often developers think about what they are building from an internal perspective and designing software in this way makes code more difficult to integrate later.
Extreme Programming centers around iterative development. Instead of designing an entire system, building it, and then validating it, which turns out to be a hugely wasteful process, we incrementally built our software, one feature at a time, starting with whatever is most important or valuable to the customer. We then create many interim releases so that we can get feedback and validation that our software works as expected.
A lot of the people outside of the software industry really don’t understand the kind of trouble that we make for ourselves in software development by trying to tackle problems that are too big and unwieldy. Extreme programming is all about taking big problems and breaking them down into smaller more manageable problems that can be dealt with more easily and with more opportunity for feedback. XP strives to fulfill the first principle of the Agile Manifesto, which is “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” That really says it all.
I used to think that building complex enterprise systems required a great deal of architecture so that common libraries would be created first and there would be a sequence or order of development, just like there is in physical construction where you dig out the basement before you put up the walls. It’s taken me decades to recognize that software development is different and that by merely focusing on building the highest value features first–the ones the customer will get the most value from first–we oftentimes end up with happier customers and are able to deliver code in a fraction of the time it would take using Waterfall development.
Practicing XP for the last two decades has taught me many refinements on these basic practices but the foundation was there from the start. Thank you, Kent. Thank you, Ron. Thank you, Ward. And thank you, the many others who have helped develop, refine, and utilize the practices of Extreme Programming.
Previous Post: « How I Use User Stories
Next Post: SO what? »