Which Requires More Discipline, XP or Waterfall Methods?
A common prejudice is that XP is an excuse for undiscplined hacking (I'm using hacking in the pejorative sense, not the original "good" sense). This prejudice arises from the mistaken notion that practitioners of XP and similar approaches just crank out code and don't do the "right" things; understand the requirements, understand the domain by modeling it and work through the design before committing it to code. All this is nothing new and I won't rehash the rebuttals here.
What's striking about XP is that it actually requires more discipline on a moment-by-moment basis; write just enough of a test to have a failing test, write just enough code to make it pass, refactor in preparation for the next iteration, etc. There is constant feedback to which you must respond and knowing what to do next requires skill and discipline.
In contrast, there is a lot less displine in Waterfall methods than first meets the eye. Sure, a disciplined waterfaller will go to the diagrams or documents first before doing any code changes (or at least retrofit the diagrams and documents afterwards). Beyond that, the waterfaller requires little discipline to constrain his or her work. There is no instant feedback validating the diagram or document. You tend to run "open loop" until you feel like you've covered enough detail, then you move to the next step. It's only much later that you get any feedback, requiring that you go way back in the process to fix the problems and then move forward again.
In other words, doing Waterfall requires discrete moments of discipline (do step 1 before step 2), but XP requires discipline all the time.
!commentForm
Hej, Dean.
For me, there are two types of discipline: the good and the bad.
The bad type of discipline is subjective: it's the one you feel. It's the one that you have to use to refuse that doughnut when you're on a diet. It's horrible. No one actively on a diet enjoys refusing that doughnut. By far the best strategy for managing this discipline is avoiding doughnut shops. If I were on a diet and faced with a selection of doughnuts on a momen-by-moment basis throughout the day, I'd quickly cave and grow to a gigantic size. I don't think you'll entice programmers (not that this was the motive behind your post) to the XP path by painting this analogy (not that you would).
The other type of discipline is the good: the objective: it's the one you watch. When you see the fantastic precision of jet-figher formation flying, or a good marching band carving into one anothers' paths without interference, you think to yourself, "Wow, must have taken hours of disciplined training to get that right." You don't yourself feel the pain of the effort they invested, but you do apprecaite it. It takes a specical individual to suffer that discipline; I know I couldn't. Is XP only for programmers with iron wills? For Marines? I don't see any crew cuts here in our shop: just tired programmers.
I think a process that assumes practicioners are disciplined will enhance the work only of those who are disciplined; I think a process that assumes that programmers are lazy, disenchanted and (dare I say it) human, will work for the rest of us.
.ed
www.EdmundKirwan.[?]com
Interesting thoughts. I think of XP as the good discipline because of those frequent endorphin hits when you get the green bar, plus the sense of pride knowing that you've created solid code, plus the ability to sleep through the night without the pager/cell phone going off...
It's interesting, too, that Kent Beck specifically said from the beginning that XP is for normal developers, not superhumans. I consider practicing XP a discipline because you have to train yourself to do its practices consistently, especially if you have old habits to break. However, the positive reinforcement makes you keep going.
I guess I would consider waterfall a bad discipline, in your terms, because I always had to struggle to "do it right". It never really felt natural and it wasn't nearly as rewarding for me as XP. -- Dean
--
"Waterfall" is a straw man. Not everything that's called "Waterfall" is properly applied classical software engineering any more than everything that's called XP or Scrum is a well executed XP or Scrum project.
Fair enough. I used "waterfall" as a catch-all term that's familiar. More accurate alternatives are "command and control" or "top-down" processes.
The correct comparison is with classical software engineering methodologies. And they take as much discipline as XP; it's just that the things that require discipline are quite different.
Most of the problems with classical software development come from not having the discipline to validate work product when it's produced, and not having the guts to find real project status and report it. The other problems come from needing a stable set of objectives up front, because it's hard to replan in the middle.
Precisely. Having grown up with the "classical" or "top-down" methodologies, I really appreciate the fact that XP and related agile processes attempt to solve these problems, which I've rarely seen handled properly in classical environments. (I should back up and say that I'm concerned with how things work in practice in a large percentage of environments vs. theory...) XP/Agile processes try to minimize the time between producing a work product and validating it. They also attempt to be honest about real status. I can't think of a better measure of this than whether or not tests for a feature pass (although I think there is not enough emphasis on the standard being passing acceptance tests vs. passing unit tests.
The issue of "stable set of objectives up front" is very important. Recently, I spoke with representatives of the large IT department of a well-known wireless provider, who are transitioning to agile. It used to be that their projects had stable, predictable requirements and they had more money for resources (i.e., people) to development solutions. Those are two essential ingrediants for classical (waterfall?) methods to work. These days, most projects have volatile requirements, no matter how hard we try to pin them down up front, and pressure to be as cost-effective as possible. Agile is the only approach for these cases, that I know of.
If you've ever worked on a project to produce, for example, avionics software, you'd know the amount of discipline that real classical software engineering requires on a moment by moment basis. Both PSP (Personal Software Process) and TSP (Team Software Process) take a huge amount of discipline to capture the measurements and apply them.
I hope you've had the pleasure of experiencing such a project. Unfortunately, I haven't. I've worked on medical software, subject to similar FDA scrutiny, and the daily discipline of the team was not good, not nearly as good as a properly-functioning XP team would be. We managed to satisfy FDA expectations and deliver the products (late...), but I suspect that most teams in regulated disciplines are less disciplined, "moment-to-moment", than an experienced XP team is disciplined. This is just a hunch, though!
XP has different problems. For example, how do you do a project where you have to certify less than 1 residual defect per 100 kloc? How do you handle large projects? Distributed teams? Projects where software is only part of the product? Working as a solo practitioner? People are doing some of that, but as far as I know there aren't any available books on those subjects.
There certainly isn't enough information on how people are handling these situations and I think this is the most important direction for growth of agile technologies. Concerning scalability, my philosophy is a shameless rip-off of that old bumper sticker; "Think globally, XP locally".
My observation is that doing anything well requires a similar amount of discipline. That has nothing to do with the subject, it has everything to do with what people can do.
No argument here. I would hope that XP makes it easier for people to do the right things. -- dean
John Roth
Fair enough. I used "waterfall" as a catch-all term that's familiar. More accurate alternatives are "command and control" or "top-down" processes.
The correct comparison is with classical software engineering methodologies. And they take as much discipline as XP; it's just that the things that require discipline are quite different.
Most of the problems with classical software development come from not having the discipline to validate work product when it's produced, and not having the guts to find real project status and report it. The other problems come from needing a stable set of objectives up front, because it's hard to replan in the middle.
Precisely. Having grown up with the "classical" or "top-down" methodologies, I really appreciate the fact that XP and related agile processes attempt to solve these problems, which I've rarely seen handled properly in classical environments. (I should back up and say that I'm concerned with how things work in practice in a large percentage of environments vs. theory...) XP/Agile processes try to minimize the time between producing a work product and validating it. They also attempt to be honest about real status. I can't think of a better measure of this than whether or not tests for a feature pass (although I think there is not enough emphasis on the standard being passing acceptance tests vs. passing unit tests.
The issue of "stable set of objectives up front" is very important. Recently, I spoke with representatives of the large IT department of a well-known wireless provider, who are transitioning to agile. It used to be that their projects had stable, predictable requirements and they had more money for resources (i.e., people) to development solutions. Those are two essential ingrediants for classical (waterfall?) methods to work. These days, most projects have volatile requirements, no matter how hard we try to pin them down up front, and pressure to be as cost-effective as possible. Agile is the only approach for these cases, that I know of.
If you've ever worked on a project to produce, for example, avionics software, you'd know the amount of discipline that real classical software engineering requires on a moment by moment basis. Both PSP (Personal Software Process) and TSP (Team Software Process) take a huge amount of discipline to capture the measurements and apply them.
I hope you've had the pleasure of experiencing such a project. Unfortunately, I haven't. I've worked on medical software, subject to similar FDA scrutiny, and the daily discipline of the team was not good, not nearly as good as a properly-functioning XP team would be. We managed to satisfy FDA expectations and deliver the products (late...), but I suspect that most teams in regulated disciplines are less disciplined, "moment-to-moment", than an experienced XP team is disciplined. This is just a hunch, though!
XP has different problems. For example, how do you do a project where you have to certify less than 1 residual defect per 100 kloc? How do you handle large projects? Distributed teams? Projects where software is only part of the product? Working as a solo practitioner? People are doing some of that, but as far as I know there aren't any available books on those subjects.
There certainly isn't enough information on how people are handling these situations and I think this is the most important direction for growth of agile technologies. Concerning scalability, my philosophy is a shameless rip-off of that old bumper sticker; "Think globally, XP locally".
My observation is that doing anything well requires a similar amount of discipline. That has nothing to do with the subject, it has everything to do with what people can do.
No argument here. I would hope that XP makes it easier for people to do the right things. -- dean
John Roth
To me,it is good that XP requires more uniformly distributed discipline. It is good that,therefore,it is less tiring -more natural-to humans.I feel, as long as we are possessed by the fruits of discipline,
we are not free enough to do(be)natural and "naturally" we will not enjoy our doing. On the other hand, I
imagine we are headed towards nature coming back(XP and the likes are steps)to us again,albeit, a new nature which, for the lack of a more appropriate word I call e-nature(e-ified nature!). Just for one point, there is no discipline in nature. "We" see(impose)discipline in(on)it. There is being(survival)in nature. Imagine we, explicitly, substitute "survival" for "competitive advantage" as the direct(primary )driver for our business,strategy,planning,designing,down(or up!)to coding habits. Wouldn't it be a small step towards e-nature and thus joy? Forgive my undisciplined English!
You're right that nature doesn't work by "discipline, per se, but through natural "forces" like natural selection, the risk of starvation, etc. One reason I really like XP is that it behaves in a similar way; we create the artificial force of "test first" (no natural law forces us to do this...) and from that force comes positive results. --dean
we are not free enough to do(be)natural and "naturally" we will not enjoy our doing. On the other hand, I
imagine we are headed towards nature coming back(XP and the likes are steps)to us again,albeit, a new nature which, for the lack of a more appropriate word I call e-nature(e-ified nature!). Just for one point, there is no discipline in nature. "We" see(impose)discipline in(on)it. There is being(survival)in nature. Imagine we, explicitly, substitute "survival" for "competitive advantage" as the direct(primary )driver for our business,strategy,planning,designing,down(or up!)to coding habits. Wouldn't it be a small step towards e-nature and thus joy? Forgive my undisciplined English!
You're right that nature doesn't work by "discipline, per se, but through natural "forces" like natural selection, the risk of starvation, etc. One reason I really like XP is that it behaves in a similar way; we create the artificial force of "test first" (no natural law forces us to do this...) and from that force comes positive results. --dean
Add Child Page to WhichTakesMoreDiscipline