May 26, 2012 2 Comments
I started today to write down some notes on the Wrox book Professional Test Driven Development with C#. I know James Bender fairly well and have met McWherter. But as I read I hit on a pet peeve of mine: arguing via bias (emotion versus logic). I thought about reviewing the book including this information, but it would not be fair, as the book should rise or fall on the merits of the material presented and not whether the authors have a strong bias towards Agile.
Let me back up a bit. I have been on the Internet since the late 80s. At that time I had to shell in via a BBS (Bulletin Board System) and use UNIX commands to navigate. Back then, arguing without a sound logical basis led to responses from the peanut gallery, especially if your faux pas was an ad hominem attack. If I go back farther in my history, I took a few logic classes (high school and college). The point is I had a background that acknowledged an argument is only as good as the reasoning behind it. A marketer would probably disagree.
One common type of logical fallacy is the straw man argument. In the straw man, you misrepresent your opponents argument and then attack it with reasoning. Since you have set up “their” position, you can easily attack it. And that is what the author’s of the book do with the Waterfall development methodology.
The Straw Man
From page 5 of the book:
The concept behind waterfall was that every software project, whose average time span was about two years, should have every phase, from inception to delivery planned from the start.
So far, the definition is mostly technically correct. But it suggests that planning is done in a bubble. Read further:
This necessitated a long period a the beginning for requirements gathering. After all the requirements were gathered, they were “thrown over the wall” to the architects. The architects took the requirements and designed the system that would be built down to the smallest detail. When they completed this task, they threw the design over the wall to developers, who built the system.
Now this is where things start to break down. Even in the worst waterfall shop I have worked in, nobody threw things over the wall. In fact, architecture is almost always treated as a collaborative process, sometimes more effectively than others. In addition, even in larger organizations that had architecture groups, I have never seen architects isolated from developers. Maybe it happens in some organizations, but years of experience show me bad architecture is far more common than the ivory tower picture presented in the book (the words ivory tower architects are used on page 6).
Other things misrepresented:
- Waterfall testing is performed by manually running scripts (page 5) – Not since the early 80s in most shops
- All requirements are gathered early on and cemented (page 5) – While waterfall is more strict, there is a change management process when done correctly.
- The work must be estimated up front – This is technically correct, but in a good waterfall shop, estimates are estimates, not firm commitments
And here is the one that set me off:
Unlike waterfall, which seeks to control and constrain the realities of software development, agile methodologies embrace them.
Now this comment is just plain silly. Not only is it not supported by the text of the book, I am shocked that nobody called the author on this one. “Constrain the realities”? Really?
I was going to stop here, but chapter 2 has a comment that really kicked me in the gluteus maximum (page 24-25).
Imagine for a moment you are building a house. For most of us, a house is the most expensive thing we will ever buy. the opportunity to have a house built to your desires and specifications is something to be excited about. Imagine, though, that when you leave the architect’s office for the last time, you will not be allow to see the house’s progress or make changes to the blueprints or design until the house is completed. Imagine that the first time you get to see the house is the day you move in. How well do you think the house would reflect what you actually wanted? It may reflect what’s on the blueprints, but there’s a big difference between a drawing and a physical structure. Amazingly, this is how many companies still develop software.
I have to throw the bullshit flag on this one. While there are companies that attempt to develop in a box, without any feedback, they generally fall in the category “out of business”. Even in the strictest agile shops, we group functionality, have POCs, demos, and means of making changes to reflect changing business needs, goals and drivers. You don’t meet with the architect and then find what was done until the walkthrough. It may happen somewhere, but it does not happen often.
Okay, it sounds like I am picking on the authors, but what I am really on is the idea of misrepresenting something, whether it be a hacked conspiracy theory about aliens and 9/11 or a development methodology. Personally, I am an Agile junky to an extent, and a strong advocate of Test Driven Development (TDD), although I tend to move towards a more Behavior Driven Development (BDD) style. More on this in a bit.
What is waterfall?
In the waterfall methodology, you have a list of requirements you need to get completed. You also have a list of items the developers are currently working on. The full scope of the work and the current list are consolidated using a project plan, generally represented as a Gannt chart. As a particular requirement is completed, it is tested. When development is completed, the software is stabilized to eliminate bugs and released.
Okay, so what is Agile?
In the Agile methodology, you have a list of requirements you need to get completed. You also have a list of items the developers are currently working on. The full scope of the work and the current list are consolidated comparing the backlog to work done, generally represented as a burndown chart. As a particular requirement is completed, it is tested. When the development is completed, the software is stabilized to eliminate bugs and released.
Wow, they sound pretty much the same? Yes, at the high level. What are the differences?
- In waterfall, you generally try to get the FIRST PASS of the system defined through requirements before you start work. Once this first view is agreed on, you will need an approved change request with the new requirement. In Agile, you simply add the new requirement to the stack.
- In waterfall, you have gates at the end of a phase. This does not mean you cannot return to a previous phase and start forward again, or even send some of the group back into a previous stage. It does mean, when done correctly, that you get sign off at the end of a phase that the work is done, prior to moving full force into the next phase. In Agile, when done correctly, you iterate until you either clear all of the requirements, or (the bonus for the properly done Agile) until business states “can we release it now” and you go into stabilization.
- In Agile, done correctly, one aspect of development (time or features) is favored. In most cases (except Feature Driven Development), the key driver is time.Time is sliced up into small chunks (generally 2 to 3 weeks) and each piece of work is completed to at least beta quality and demoed. This is artificially accomplished in most waterfall shops, as well.
The Good, the Bad and the Ugly
There is good development and bad development. This is a truism whether you are using a waterfall methodology or an Agile one. The assumption in the book, and with many other developers who have embraced Agile, is waterfall is bad and Agile is good. Take, for example, this quote on page X:
[Agile Methods] are also not about chaos or “cowboy coding”. In fact, agile methodologies require a larger degree of discipline to administer correctly.
In many shops I encounter, Agile is chosen to facilitate a few cowboys who don’t want to plan or write documentation. I am glad the discipline is mentioned here, but it is more often missing in shops that claim to be Agile. I have heard the following in Agile shops:
- Agile is about writing requirements during development – Then why are all of your TBIs (Team Backlog Items) one liners with empty task definitions.
- My tests and code are my requirements documents – This only works if you are writing the correct tests and code.
- If you have to comment, you are not doing Agile – Okay, I agree that comments in code often explain what the code does, rather than why, making them useless. And, I agree the discipline of refactoring to eliminate the comment is a great practice. Unfortunately, most of the cowboys I have encountered that dis comments fail to refactor enough to eliminate the need for a comment, even though they do not write a comment.
- We don’t need documentation with Agile – No, we let the next group guess what our intent was and have people hack our libraries in strange ways to fit their requirements, leading to new defects that could have been avoided by documenting rather than forcing an exploration operation.
So Agile does not have a lock on good practices any more than waterfall has a lock on bad practices. Agile is another paradigm, not an evolution or revolution in development. Once you have that down, you start to realize you can take either method and make good software, or you can mix and match the best of each world. You just need everyone on board. So what is good, bad and ugly?
Bad waterfall is serial in nature,with no parallelism in the pieces. Good waterfall allows for overlap, and is fully collaborative, but signs off the phases in order to ensure things are not missed. Ugly waterfall is not only serial, but extremely rigid.
Bad agile is a group of mavericks pulling code with little response back to the business until the demo. Good agile is a collaborative effort that includes coders, business and testers in the team. Ugly Agile ends up with all code written unplanned in a stream of consciousness, often ending up with an overly complex solution that simply does not work.
The important thing to remember is you need all of the following to have a successful system built:
- An understanding of what is being built before it is built. This can be up front (ala waterfall) or as work is pulled off the stack (ala Agile), but more likely you have a hybrid of the two. Even in the strongest Agile shop, the business guy who came up with the requirement probably has a good idea what it should look like and that has to be conveyed to be effective, whether it is on paper, in a meeting, on a phone call or sitting next to you (best in Agile).
The Real World
In the real world, you find the following:
- Sans a strong case, you are stuck with a set of resources. This is a budgetary constraint.
- Whether you are Agile or Waterfall, business has an idea when they want to release and it often a stake in the sand whether you piece out the work or do it all “big bang”.
- In all systems, there is change during the project. Agile, on paper, has a better method of handling this change, but waterfall has a better method of planning and documenting the change.
In the real world, I find political fiefdoms whether the shop is waterfall or Agile. Waterfall allows a fiefdom to exist through rigid sign off procedures, so the one with the sign off pen takes control. Agile allows fiefdoms to exist by avoiding all rigidness and allowing the cowboys to take control. Both are dangerous towards getting development completed.
Which is Better?
This is like asking “which is better, steak or ice cream?” The best depends on the mood and tastes of the people going out to eat. If everyone has had lunch or it is a really hot day, ice cream will win out almost every time. But if you have not had dinner, a steak is a wonderful choice. And, if you play the dinner “date” right, you can have both steak and ice cream.
In some shops, you need the discipline of waterfall to get things done. This is especially true when an outside “agency” is doing work and it must fall within certain constraints (generally budgetary). I am not stating Agile does not work here, but keep going until we run out of money and we will pray it works as a project is a fear with Agile when this type of situation is encountered.
What I personally find is most effective is a mixture of the two. You need a certain amount of discipline and sign off to have a successful project, so pulling the gates from waterfall makes sense. During development, you need the flexibility to change, however, so running iterative cycles is a great option. You need to plan before developing, so forcing some type of up front documentation (ala waterfall) is a good thing (At minimum, you need a good definition of the use case with criteria of what acceptable means for the feature). But you also need representatives from business, development and test in the same team so progress is not impeded (ala Agile).
TDD Is Agile?
This is another misnomer I often hear. While TDD got it start in Agile shops, I have seen it effectively used in a variety of environments, including some that are extremely waterfall in nature. The same is true of many other Agile techniques, like pair programming. When we start mixing the techniques and the methodology, it becomes much easier to claim one methodology is superior, especially if we ignore techniques that are more likely employed by the opposing methodology.
The book often mixes the Agile technology of Test Driven Development (TDD) with the methodology, which helps build the straw man argument argument against waterfall. Unless we assume it is impossible to unit test in an upfront manner with waterfall, we cannot use TDD against the waterfall methodology.
Neither Agile or waterfall is a superior methodology in all cases. When done well, with the right business culture, either can be extremely effective. Done badly, both can be detrimental. Bad waterfall generally gets bogged down in process, delaying work that needs to be done. Bad Agile leads to unplanned and undocumented work, which requires tons of rework to get to a stable release.
In my experience, I find Agile done bad to be more dangerous, as overly rigid process generally has less impact on quality and maintainability. But I am still more inclined to push Agile as the primary methodology, as I find good Agile much more likely to produce good results.
(Not quite true, as I find using the gates after you pull the trigger to release, adds control to the chaos that might otherwise ensue).
Peace and Grace,