Will XP help you cope with change as its supporters contend, or is it just glorified hacking? Jack reports on how the controversy is going.
Scrum, XP, TDD, FDD, DSDM, PSP, RUP, and so many other acronyms that describe various development processes pepper the literature of software engineering. Sometimes it feels like we're as subject to fads as the fashion industry. Most fall under the general moniker of agile development , a decade-old movement that's pushing against traditional big-up-front design.
The embedded world is populated by engineersa mostly conservative lot, not prone to radical restructuring of political institutions, our personal lives, and, most of all, our development processes. Up-front design is still an accepted practice in firmware development.
At the start of a project we whip out Microsoft Project and start diddling triangles against dates, struggling to develop The Schedule, the map which supposedly guides the entire project. The result is a waterfall model, a sequence of activities beginning with finding requirements and progressing through specification, design, coding, test, and shipping.
Upon seeing The Schedule the boss recoils in horror at the eight month lead-time we anticipate. “The show is in two monthsit's gotta be done by then. Or you're all history.”
So, we fire up Project again and slide the bottom triangle waaay to the left. Errors pour off the page as the tool warns of conflicts. We juggle subtask triangles, taming the tool, creating what we hope is a believable scheduleknowing that no one will believe it except the boss. If we can stave off the inevitable failure for even a few months then just maybe a miracle will save us.
The cool people
Various luminaries created The Agile Manifesto (agilemanifesto.org) as a response to the up-front design's flaws. Their seductive arguments contain much wisdom, gleaned from numerous failed projects.
Observing that requirements change throughout a project, the agile crowd embraces change and welcomes modifications at every phase of the project.
The agile crowd believes great programmers make the best team members. Well, duh. But what happens to the less-than-great developers? It's statistically impossible for everyone to be above average. Managers can't ignore the fact that some team members just won't be as awesome as the agile crowd demands.
The agile crowd disses schedules. “Great software takes time; it'll be done when it's done,” they say. Though there's much truth in this, real business pressures demand schedules. Sometimes it's geometry that governs deliveries; a narrow window happens only every couple of years in which to launch a spacecraft to Mars. Miss it, and you physically can't deliver the mission for years to come. Less dramatically but just as important is ensuring adequate cash flow: get the product into the market so the company can pay its bills.
The most visible agile method today is eXtreme Programming (XP). Software literature abounds with stories of XP; some 20 books promote the idea. Originated by Kent Beck, enhanced by dozens of others, XP sometimes seems to be taking the software world by storm.
XP's philosophy is that everything changes all of the time. People, tools, requirements, features, and the code are all in a constant state of flux. Instead of trying to immobilize the world, to institute a halt while we generate a project that meets today's specs, XPers embrace and even try to provoke change. Beck believes that software projects work best when guided by many, many small course corrections rather than just a few big ones. As he puts it, “The problem isn't change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes.” That's a laudable concept. However, the implementation leaves, in my opinion, much to be desired.
Traditional software engineering attempts to delay coding until the requirements are nailed down. In XP the code is everything. Jump in and start coding today. To quote advocate Ron Jeffries, “Get a few people together and spend a few minutes sketching out the design. Ten minutes is idealhalf an hour should be the most time you spend to do this.” Then start coding.
Needless to say that's a radical notion, one that frankly terrifies me. Embedded systems usually don't have a Windows Update feature. They've got to be right; in some cases errors can lead to death. Ten minutes of design is not the path to carefully-analyzed software.
XP takes a few software engineering ideas which work, and, as they say, turns the dial up to 10. If code inspections are good (and they are), then inspect constantly. In fact, programmers work in pairs, each pair sharing a single machine. They take turns typing while the other audits.
If tests are good (and they are), then let the tests define functionality. Developers create tests in parallel with their code; no function is done until it passes all of the tests.
If customer interaction is good (and it is), then in XP you may not develop any code unless a customer lives with you, spending 40 hours a week with the team. The on-site customer compensates for the lack of a spec; developers constantly lob questions at this (presumably savant-like) team member.
If bad code should be trashed (and it should), then all code is “refactored” (rewritten) whenever it can be improved, and by any team member, since everyone is responsible for all of the code.
XP is a fascinating and different approach to the problem of developing software. I'm entranced with their test-first, test constantly, and don't-move-on-till-the-tests-pass philosophy. If only most of us practiced such aggressive checking! Refactoring is also a great idea, though I'd argue that we should attempt to write great code from the outset, which minimizes the number of refactorings needed.
Unfortunately XP has grown into a bible-thumping religion (the bible, though, is in this case Extreme Programming Explained: Embrace Change by Kent Beck).1 Few question its dogma, all sing the hymns of refactoring and pair programming. There's been a paucity of counter-reformation ideas. Until now.
Like Martin Luther's 95 theses, Matt Stephens and Doug Rosenberg's new book Extreme Programming Refactored lifts the hood on the hype and exposes the problems that come with XP.2
Just as educated Christians should read what's available of the Talmud (at least, the little that's been translated into English) to understand better an important and interesting part of our world, all educated developers should go dig through a couple of XP tomes. And then read this book, which in the agile spirit I'll dub XPR.
XPR is the most infuriating programming book I've read. The message is spot-on but told in such an awful manner that it's sometimes hard to hear the reasonable thoughts for the noise. Like the lyrics to 40 (I counted) annoying XP-bashing songs littered randomly in every chapter.
Sometimes witty, XPR is often entertaining in the manner of The National Enquirer or a car wreck. Though the authors repeatedly express dismay at how XP zealots attack doubting Thomases, they themselves wage near-war against the XP personalities. An entire chapter belittles the opposition's personas. A special overused icon warns the reader of yet another tiresome bout of sarcasm.
The book, however, carefully and correctly demonstrates how all 12 of XP's practices are interrelated. Drop one and the entire game falls apart like a house of cards. Testing is the only defense against poor specs; pair programming an effort to save the code base from a poorly thought-out, frantically hacked-together creation. The book is worthwhile for this analysis alone. XPers generally don't stress how vital all 12 steps are to success on a project.
Yet the authors, in the few demonstrations of failed XP projects they present (no successes are noted), sheepishly admit that none of these programs were built using an unmodified form of XP. All used subsetsthe very approach XPR demonstrates cannot succeed. So the credibility of these examples suffers.
Also, a sidebar cleverly titled “The Voice of eXPerience” quotes disgruntled programmers who used (subsetted) XP. Actually, I think only the same two programmers are quoted, over and over. One pontificates: “My feeling is that XP wouldn't score highly at all when compared to other available principles.” That may be true, but that statement itself isn't a convincing demonstration of proof.
The authors do miss a couple of other arguments that indict XP-like development processes. The agile community calls the test strategy XP's “safety net”; they say it ensures bad code never makes it to the field. Yet study after study shows tests don't exercise all of the softwarein some cases less than half! I'd argue that tests are the safety net that catch problems that leak through code inspections, design checks, and careful design. In the embedded world, the automated tests required by XP are devilishly hard to implement, since our programs interact with users and the real world.
XPR completely ignores embedded systems, rather like, well, rather like every other software book. One anti-XP argument for an embedded project is that without some level of up- front design you can't even select the hardware. Do we need an 8051 or a Power PC? Is data trickling in or gushing at 100,000 samples per second?
XPR concludes with a modified version of XP that's less eXtreme, more logical, and better suited to firmware development. That chapter is the best part of the book.
Now don't get me wrong. I do believe there are some programs that can do well with XP. Examples include nonsafety critical apps with rapidly changing requirements that simply can't be nailed down. Web services come to mind. I know of one group that's been quite successful with XP in the embedded space, and numerous others who have failed.
Should you read the book? If the siren song of XP is ringing in your ears, if pair programming sounds like the environment you're dying to work in, read XPR today. Others wishing for a balance to the torrent of pro-XP words flooding most software magazines will find this book interesting as well. If it had been a third as long, without the revisionist Beatles lyrics, and, well, more polite, it would deserve five stars.
Beck's new book
XP's motivating guru, Kent Beck, also has a new book out. Test Driven Development: By Example focuses on XP's testing practice.3
I bought the book because I'm fascinated with testing, which is usually done as an afterthought and rarely hits the hard conditions. Unit tests are notoriously poor. The programmer runs his new function through the simplest of situations, totally ignoring timing issues or boundary conditions. So of course, the function passes the test, only to inflict the team with agony when integrated into the entire system. XP's idea of writing the tests in parallel with the code is quite brilliant; only then do we see all the possible things that can go wrong.
Beck argues for building tests first and deriving the code from these tests. It's sort of like building a comprehensive final exam and then designing a class from that. An intriguing idea.
But what if the test is wrong? Test Driven Development (TDD) then guarantees the code will be wrong as well.
Worse, TDD calls for building even the smallest project by implementing the minimal functionality needed to do anything. Need a function to compute the Fibonacci series? Create the simplest possible test firstin this case, check to see that fibonacci(0) is 0. Then write a function that passes that test. Try fibonacci(1) ; that breaks the test, so recode both the test and the function. Iterate till correct.
The book shows how to build a factorial program, which results in 91 lines of code and 89 of testafter 125 compilations! Klaxons sound, common sense alarms trip.
Agile proponents love the interactive and fast action of this sort of method. But programming isn't about playing Doom and Quake. If you're looking for an adrenaline rush try bungee jumping.
One hundred and twenty-five compilations for a trivial bit of code is not fast. Dynamic? You bet. But not fast.
Oddly, the test examples given in the book are exactly like the ones I see dysfunctional programmers creating for their unit tests. None check boundary conditions, like the overflow that any factorial routine is bound to produce for even rather small inputs.
When a problem occurs he says: “Rather than apply minutes of suspect reasoning, we can just ask the computer by making a change and running the tests.” Yikes! What if the change seems to work, but in actuality masks some deeper problem? He seems to advocate removing thinking from programming, a very dangerous proposition.
This is a fast world: fast food, drive-through liquor stores, ATMs on every corner, and instant messages. But software needs thought. Slow down when you find a problem. Think deeply. Understand the implications of proposed changes. The alternative is making almost random changesglorified hacking. esp
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at .
1. Beck, Kent. Extreme Programming Explained: Embrace Change . New York, NY: Addison-Wesley, 2000.
2. Stephens, Matthew and Doug Rosenberg. Extreme Programming Refactored . New York, NY: Springer-Verlag, 2003.
3. Beck, Kent. Test Driven Development: By Example . New York, NY: Addison Wesley, 2003.
I used to sleep like a baby. Then I read your latest assessment of XP.
I used to sleep soundly when I thought XP was just a fad that had certainly come and gone. Createdby someone who couldn't program, and so decided to make money with a preposterous idea for a bookthat a few would buy. After all, what better way to prove you're a real cowboy than to strapyourself to the back of the XP horse?
But now, if I understand the article, I find that XP is still going strong, maybe even on theupswing!
XP reminds me of my son at about age 12. High IQ, low patience, way too much time on his hands,sitting in front of the TV frantically pushing every button on his Nintendo until he figured out howit and the game worked. Never time to read the manual or any of the help files, just try somethingelse until you get the desired effect then move on.
That scenario gets by on the Nintendo, but now you have me believing that the heart monitor sittingnext to my Dad might have been programmed by the same technique. Now I get on an airplane wonderingif there is XP code on the rudder control. If my car cranks a few revolutions too long in themorning, I hear the programmer's partner yelling out “this interrupt routine's not working – tryjust polling it once in a while!”.
Thanks a lot, Jack.
Enclosed you'll find my latest receipt for Ambien. Cash, check, or credit card please.
– Ray Zeune
“Also, a sidebar cleverly titled “The Voice of eXPerience” quotes disgruntled programmers who used(subsetted) XP.”
I was a “voice of eXperience” and my shop used XP by the book, trained by Object Mentor, and givenan 85% rating by their auditor. I was not doing “subsetted” XP. Perhaps I'm just imagining this,however, I sense that you're discounting my tesitmony or it's relevance because I was “disgruntled”.
1. We were forced to work shoulder to shoulder in a room. One lab that I didn't work in had nearly70 developers. It was literaly a sweatshop, and it's creation was all made possible by way of XP.
2. We had “snacks” in the room as is normally the practice in XP and as a result we had miceand bug issues.
3. When you occupy a room with 15 people, you get to listen to endless conversations about thelatest friends episode, religion/political arguments, and become aware of personal information thatyou'd rather not know. There is no escape from this because the lab is your workplace.
“Yet the authors, in the few demonstrations of failed XP projects they present (no successes arenoted), sheepishly admit that none of these programs were built using an unmodified form of XP. Allused subsets”the very approach XPR demonstrates cannot succeed. So the credibility of these examplessuffers.”
Jack, this is the point. It is impossible to find a project that failed and did XP correctly. That's the trick used against anybody brave enough to oppose this nonsense, and ironically you aredoing it too. Nobody, even Beck, does all of these things all of the time. It is like the 10commandments, all fall short. These long lists of practices and values are just a way for XPzealots to discredit any detractors. Failed XP project? Then you didn't do the __nt practicecorrectly. Furthermore, there isn't really a fixed list of practices. If you go to Ron Jefferiessite you get one list, then if you go to Object Mentor you get a slightly different list. So whichlist defines the set of practices that would allow one to say they didn't use “subsetted” XP? Thereisn't one. XP is a type of religion, or a life philosophy heavily influenced by Marxism and secularhumanism. No self respecting young professional would consider it a good job after viewing a realXP lab. If I were younger I'd be considering a career change, as software development under XPconditions is hardly white collar. It's adherents are quite simply nuts, and the only response tothat is to either make fun of it (sarcasm) or ignore it. It's impossible to oppose with logic.
Disgruntled former XP developer,
– Taylor Cowan
Thanks for writing your “XP deconstructed” article. You learn more bystudying an issue from both the pro and con sides.
“The book shows how to build a factorial program, which results in 91 linesof code and 89 of test-after 125 compilations! Klaxons sound, common sensealarms trip.”
I agree, that made me shudder too. So much wasted effort for something thatyou could do faster and more thoroughly with some upfront design. It's not avery impressive example of XP's virtues.
But maybe we're not the intended audience for the book. The factorialproblem is a math problem, and most of us are engineers who are comfortablewith math. We know that there's knowledge out there that can help us designa solution, and we know how to find it. Perhaps to the average XPer, thefactorial problem is this mysterious black magic thing (due to theirparticular education/experience and nothing to do with intelligence) and sothey're unable to do upfront design. In which case, the XP way might makesense.
XP sounds more like eXPerimental science as opposed to theoretical science.Experimental science is something you do when you're pioneering a completelynew field. You don't have a body of knowledge to draw upon, so you're juststabbing around in the dark, but at least you're doing it in a methodicaland efficient manner.
I think it boils down to this: It's ignorant to over design. It's lazy tounder design. Designing upfront has many benefits, so you should do as muchof it as you can. But there's a limit to design when we don't have enoughinformation (ambiguous specifications, a lot of unknowns, customers changingtheir mind, etc.). That's when you can apply XP methods because theyemphasize reducing the feedback cycle, and feedback is what gives us theinformation we need to do useful design.
Mary Poppendieck has some wise words about methodologies. We have toremember that XP is a bunch of _specific practices_ for developingapplication software in a certain environment. Though it's convenient, itwould be dangerous to transplant them directly to embedded software. It'sfar more useful to learn the _principles_ that they're based upon, so thatwe can craft our own practices, for our unique situation. Practices can'ttell you when and when not to use them, principles can.
– Vinh Pham