Already on his first day of classes at the University of Oregon, at the very young age of 18, Agile demigod Kent Beck somehow knew he was destined for greatness. As the head of his department sombrely discussed the likeliest outcome for the future of software development — a grim reality in which programmers would take a single concise problem and carefully break it down into perfect, inerrant code — Beck was filled with an impending sense of horror at the thought of the work he loved reduced to a soulless machine.
This cannot be the future, he told himself. I’m gonna change the way people do that.
A native of the energetic Silicon Valley, to Beck, programming was never a mere production activity, where you sit at your desk and arduously crank out widgets; but in his own words, “a learning, exploratory experience; an intensely creative act and something that is both intellectually and emotionally absorbing.” Rightly so, therefore, he was determined to see his vision through on a much grander, global scale.
In March 1996, his chance finally came. Working as a consultant for US car manufacturer Chrysler, Beck was invited to lead development of C3, a payroll system that for months on end had been left in a state of utter disarray.
And so, with little choice and visibly shaking hands, he agreed to take over the project.
The Birth of a Revolution
A week later, Beck was back at Chrysler, sitting down with C3’s PM.
“So, how is this project going to run?” the project manager inquired.
In reality, Beck had no idea whatsoever, but based solely on his previous experience, astoundingly, he went on to completely improvise what eventually became known as Extreme Programming (XP) — one of the single most impactful development methodologies of all time.
As he later would say of the feat, “inspiration is preparation plus panic.”
Core Practices
With his tenure at Chrysler proving wildly successful, Beck decided to encapsulate the essence of his newfound process in the first book he published, Extreme Programming Explained. In it, he describes 12 core XP practices:
1. The planning game
The first practice is the Planning Game, in which developers and business leaders cooperate to efficiently generate maximum business value. After putting together a list of desired features, businesses hand over their requirements to developers, who convert each and every one of them into bite-sized user stories. These are then written onto 4×6 cards and estimated as to how much time they will take to implement, and how many stories can be delivered with every iteration. Finally, business representatives prioritise each story to determine the ones to implement and in which particular order.
2. Small releases
Beck argues that it is crucial to begin with the smallest useful feature set and release both early and often, incrementally adding new features.
3. System metaphor
Every project is given its own naming convention through the use of an ingenious system metaphor that can bridge the communication gap between jargon-prone businesspeople and techy programmers.
4. Simple design
A minimalist before it was even cool, Beck believed that you should always make use of the simplest possible design in order to get the job done as efficiently as possible. Because requirements may change tomorrow, it is vital to only work on what is needed for today.
5. Continuous testing
The general Extreme Programming reasoning is that if a little testing serves to eliminate a few problems, then a lot of it will likely do away with many more issues. This idea had been staunchly advocated by Beck even prior to developing XP, when he first came up with the exceptional Test-Driven Development. Following this approach, before writing any code, XP programmers must first write a failing test. These may be done by using a unit testing framework such as JUnit — incidentally, also created by Beck. And finally, as part of Continuous Testing, acceptance tests are then run to decisively certify that the whole system is working as expected.
6. Refactoring
According to this practice, code should be kept simple, with short functions and without duplication, as this is easy to be read and understood by other programmers. These standards are only possible with a thorough review of code. On that note, by the way, the tests that were used before should also come in handy, as they enable developers to do this with greater confidence — in the knowledge that nothing will in any way be broken.
7. Pair programming
All production code should be written by not one, but two programmers, sitting side-by-side at the very same machine. While one developer writes code, in real time, the other evaluates everything that is being written. This should lead to vastly superior code, as two heads are better than one.
8. Collective ownership
No single person may ever be considered the exclusive “owner” of any particular module. Instead, every developer must be fully capable of editing all parts of the pertinent codebase, should ever the need arise. This, of course, calls for full-stack expertise.
9. Continuous integration
At least once a day, all changes are to be integrated into the relevant codebase and deployed to the staging environment.
10. Sustainable pace
In the long run, overtime is detrimental to productivity, so Extreme Programming strongly suggests that at the end of the day, developers should be permitted to finish work and go home on time. Although in crunch mode, up to one week of sustained overtime is permitted, if multiple weeks are required, it is taken to mean that something somewhere has gone terribly wrong and demands immediate attention.
11. On-site customer
The development team is given continuous access to the customer; or in the case of commercial software with a large number of end users, a customer proxy such as the product manager.
12. Coding standards
Finally, when all is running smoothly, you should never be able to correctly identify the person responsible for any portion of your code, as every input is perfectly standardised and will tightly adhere to the same naming conventions.
Two Decades On
While the values and principles introduced by Extreme Programming were nothing short of revolutionary at the time — and to this day, continue to leave their mark — XP’s main influence on the development community is seen in its outstanding collection of best practices in engineering.
In fact, even though nowadays, many teams transitioning to Agile will usually begin with a different development process, eventually, they are likely to feel the need for greater discipline and order, and as a result, adopt the best practices that we’ve outlined above.
Extreme Programming at SPG
At Software Planet, since 2006, Extreme Programming has had a major impact on our company. Our Ukrainian office was featured on C2’s Extreme Programming wiki page in a list of pioneers who adopted all of XP’s 12 practices. Though we now make use of the Scrum methodology, XP’s proven methods like Pair Programming and Test-Driven Development are still very much apart of our day-to-day activities.
For this reason, with every pun intended, we are extremely grateful for Kent Beck’s contribution, as we believe it was leaps and bounds ahead of its time, represented a major advancement in business-programmer relationships, and just as the developer had intended to do — Beck was one of the original signatories of the Agile manifesto — laid the groundwork for the future of software development.
