20.5 Years of XP and Agile
Within the fall of 1999 I bought the most important productiveness increase of my complete profession as a software program developer. Within the October concern of IEEE Pc journal, there was an article by Kent Beck referred to as “Embracing change with excessive programming”. In it, he outlined Excessive Programming (XP), which incorporates a lot of what we now consult with as agile improvement.
By then, I had been working as a software program developer for seven years. The usual improvement methodology at the moment was waterfall: document-heavy year-long initiatives, frozen necessities, change management boards, handbook testing on the finish of the venture, and so forth. Software program improvement succeeded regardless of the methodology, not due to it. Studying the article was an actual eye-opener. I felt it was describing how I naturally labored – briefly cycles, with quick suggestions, and frequent redesigns.
(And sure, I meant to write down this final fall for the twentieth anniversary, however I didn’t get round to it then. However hey, higher late than by no means, even when the title has 20.5 in it now)
Waterfall
Within the Nineties I labored as a software program developer for Ericsson, growing software program for cell phone exchanges. The initiatives for brand new releases of the software program had names like 91B (for Q2 1991) and 92C (for Q3 1992). A typical venture at the moment lasted for a 12 months or extra. The methodology was typical waterfall: requirement paperwork have been written and handed over to builders. We builders applied the options, and documented them with elaborate circulation charts that no person ever checked out. Testing was largely handbook, and carried out on the finish of the venture. If there have been adjustments to the necessities, they needed to be accepted by a change management board earlier than they have been applied. By the flip of the millennium at Ericsson, we additionally had Rational Unified Process (RUP) and an terrible device for producing code from UML diagrams referred to as ROSE.
Despite the fact that I solely labored at Ericsson (albeit at a number of completely different places), my feeling is that one of these waterfall methodology was the dominant methodology for many software program improvement on the time. It was definitely how I used to be taught software program improvement at college.
And it appears so affordable! In the event you can’t get the whole necessities for what to develop, how are you going to do an excellent job growing it? And in the event that they necessities are allowed to vary, you jeopardize what you’ve already carried out. However I struggled getting the waterfall methodology to work for me. It was all the time too exhausting for me to provide you with an entire design, after which implementing it. As an alternative I’d make a extremely tiny model of what I wanted, and take a look at that. Then I’d add the wanted performance little by little, all the time testing and operating the code alongside the way in which. As I developed, I’d have new insights into the issue I used to be attempting to resolve, and about how the answer ought to be structured.
Agile
After I learn the article about XP, I instantly felt that it aligned very well with what I had found labored for me. As an alternative of following a inflexible plan and preventing in opposition to adjustments, the article outlined a complete improvement methodology primarily based on permitting and inspiring adjustments.
There have been in fact many different issues within the article that I had not found for myself, however that appeared like such good concepts after I examine them. For instance, I actually favored the idea of unit assessments. After I wrote my code in tiny increments, I’d usually take a look at the brand new code I had written, to achieve confidence that it labored. Nevertheless, these have been all the time one-off assessments that I didn’t save. The concept of conserving all these little assessments in a take a look at suite that may very well be run many times was nice.
One other nice concept was to design with testing in thoughts. I nonetheless keep in mind the aha-moment after I modified the code to make it simpler to unit-test, and noticed how a lot cleaner the design of this system grew to become. One other nice concept was refactoring. That is one thing I did every now and then, however having a reputation for it, and arguments for why it’s wanted, was actually good.
Nevertheless, an important adjustments XP (and what later grew to become agile) introduced weren’t particular practices like unit testing and refactoring. An important adjustments have been the themes of iterative improvement in small steps, with quick suggestions and frequent changes to what we’re growing. These core concepts are virtually the alternative of the concepts of waterfall. At present, it appears to me that agile gained. Virtually all corporations attempt to use agile methods of growing software program. Not all succeed maybe, however the aspiration is there.
Conclusion
Waterfall is nice in principle, but it surely doesn’t work properly in follow. 20 years in the past I found and switched to utilizing agile methodology as a substitute. There the emphasis is on iterative improvement, ceaselessly delivering small slices of performance, with quick suggestions and lots of changes. Altering to this fashion of working was the most important productiveness increase of my profession, and it’s working as properly in the present day because it did after I switched. Thanks Kent Beck to your nice concepts!