Otaku – Cedric's blog

176 Comments

• #1 by Sam on June 7, 2006 - 11:38 am

  

  Have you ever worked on a *real* Agile project? I don’t mean the fake shit that most people refer to as “Agile” or “XP”, etc. I mean the real deal where people actually follow the prescribed principles without comprimising it to hell. I highly doubt it since those projects are, in truth, very rare.
  Here’s some truth for you Cedric. I worked on a *real* XP project. We did the full deal — no bullshitting around like most “XP” projects. I started on the project very skeptical of the whole thing since I’d never done XP before. At the end of it, I was completely convinced of its efficacy. It was the most productive project I’ve ever worked on. Most of the projects I’ve been on don’t even come remotely close to that one. And yes, it was for a REAL project — not some made up bullshit to make XP look better.
  My point is that until you do it, you have no business talking shit about it. There’s a reason why Agilists sometimes have an elitist attitude: it’s because a properly run Agile project will kick ass over the traditional processes with ease and they know it because the’ve ACTUALLY DONE IT.

• #2 by mmatt on June 7, 2006 - 12:05 pm

  

  Sam, that’s all shit, too. (And extremely close to the “Well, if you had started with TDD in the first place, you wouldn’t be having this problem today” comment from the presenter.) It’s that same dogmatic BS that Cedric is slamming–and rightly so.
  Putting yourself on a pedastal elevates you out of the real world trenches. I’ve had the same experience with super-awesome XP projects, but have also seen the same practices fall apart on the next project with the same exact team in place with the same exact practices. When I read your comments (especially with the added emphasis on ‘real’), I think noobie, ignorant, or boutique developer. The minute you try to push your crap around in a larger, slow-moving company, you’ll hit so many roadblocks, you’d likely quit.

• #3 by pixel on June 7, 2006 - 12:06 pm

  

  Sam, that’s all shit, too. (And extremely close to the “Well, if you had started with TDD in the first place, you wouldn’t be having this problem today” comment from the presenter.) It’s that same dogmatic BS that Cedric is slamming–and rightly so.
  Putting yourself on a pedastal elevates you out of the real world trenches. I’ve had the same experience with super-awesome XP projects, but have also seen the same practices fall apart on the next project with the same exact team in place with the same exact practices. When I read your comments (especially with the added emphasis on ‘real’), I think noobie, ignorant, or boutique developer. The minute you try to push your crap around in a larger, slow-moving company, you’ll hit so many roadblocks, you’d likely quit.

• #4 by Tim on June 7, 2006 - 12:35 pm

  

  There is a distinct lack of agility displayed by many Agilists these days. This is just another example of it. See http://pliantalliance.org for my backlash.

• #5 by Agile Thugz on June 7, 2006 - 12:37 pm

  

  Hizzy you ever worked on a *real* Agile project? I dizzon’t mean tha fakes S-H-to-tha-izzit tizzle most thugz refa ta as “Agile” or “XP”, etc. I mizzle tha rizzle deal where thugz actually follow tha prescribed principles witout clockin’ it ta hizzle fo’ sheezy. I highly doubt it since those projects are, in truth, very rare.
  Here’s some truth fo` you Cedric from tha streets of tha L-B-C. I worked on a *real* XP project. We did tha full deal — no bullshitt’n around like mizzy “izzy projects . Chill as I take you on a trip. I started on tha project vizzle skeptical of tha whole thing since I’d neva done XP before . Im crazy, you can’t phase me. At tha end of it, I was completely convinced of its efficacy. It was tha mizzy productive project I’ve ever worked on with the gangsta shit that keeps ya hangin. Most of tha projects I’ve been on don’t even come remotely close ta T-H-to-tha-izzat one mah nizzle. And yes, it was fo` a REAL project — not some made up bullshit ta makes XP look betta

• #6 by Alex on June 7, 2006 - 1:01 pm

  

  IMHO, your post would be best served by replacing the term “agilists” with “some TDD book authors and speakers”. Having attended many of the agile conferences and countless user group meetings, I hear you. Not that you won’t find the exact same thing at OOP, BDUF, SQA, etc conferences…
  I have a lot of respect for what Uncle Bob, Michael Feathers, Brian Marick and others have accomplished and pursued. As in increasing the lines of test code written by programmers that used to look down their noses at it. I’ve been at several companies where this has improved thanks to these folks and others. Not that our little silicon world is perfect, but it is a better place now with bad “test engineers” replaced by better “extreme programmers”.
  Lets not forget that *a lot* of the folks your post refers to as “agilists” spend most/all of their time writing better code and tests — and not going around and talking about it. Coding solutions for real problems is more fun than presenting Stack examples!
  Keep up the writing and sharing your perspective. Agile’s failures and mistakes won’t kill us, they’ll only make us stronger 🙂
  I still hope you find yourself in Colorado to speak for our “agilists” group — maybe a panel “Otaku vs Langr” 😉

• #7 by fanguad on June 7, 2006 - 1:29 pm

  

  I’ve never worked on a “real” Agile project, but I do know one thing – Agile isn’t a panacea, not even close. I work on a project that *can’t* be Agile. We have hundreds of developers spanning dozens of different companies and divisions. Many of the things I’ve seen Agilists attribute to themselves (lots of tests, good customer interaction) are more the hallmarks of a good team, rather than methodology.
  When someone else on this project inevitably needs to understand my code, “self-documenting code” and unit tests aren’t going to cut it. Likewise, they’d be equally unhappy with obtuse code lacking any form of testing. Any shortcuts are going to make that person’s job harder. Agile promotes certain shortcuts, while (for example) waterfall promotes others.
  I’m going to make an appeal to the moderates here: pick the tool that does the job. For some projects, Agile is appropriate, for some it isn’t. For some (and here I’m covering my head) it probably doesn’t matter what technique you pick if you have good people.

• #8 by matthew on June 7, 2006 - 1:40 pm

  

  It seems that a lot of Agilists aren’t interested in solving problems, instead they are only interested in re-packaging and re-selling the same ideas in as many consultation gigs as possible.
  For a methodology to be truly useful, I need to be able to apply different pieces in different places at different times, to different degrees. I’ve been able to do this with some aspects of XP/TDD over the years, and I’ve been pretty happy with the results.
  But statements like “you wouldn’t have those problems if you started with TDD” hint at an all or nothing philosophy. You must start with XP, and use XP for everything, or you will fail, and cannot legitimately complain about it.
  What value is there in a solution if you can’t inject it at any point in the software process? Isn’t that the definition of refactoring: improving the design of *existing* code?
  @Sam: So anybody who hasn’t worked on a “real” XP project shouldn’t be able to criticize it? Well, I guess that’s a clever way to eliminate 99.9% of developers from the argument. You and that other 0.01% should have a blast at the TDD tug-off 2006.

• #9 by Carsten Saager on June 7, 2006 - 2:24 pm

  

  What is a real and pure Agile or XP-project? Besides some interesting exceptions, their existence is as likely as the tooth-fairy or Santa Clause.
  Real-world projects, as I understand Cedric, are where you have to compromise. If your “process” only works if you follow it 100% it is useless, because this will virtually not happen at all.
  The point I draw from Agile is to draw back more responsability and responsiveness to the implementation team which is a good thing.
  A word (or some more) on tests: I neither like tests as a replacement for documentation nor specification. As “code stays forever” documentary test-cases have a tendency to reflect overcome uses. As specs they are simply too limited and raise the question who will implement them. Nevertheless, tests which show proper use are important as they show the functionality in its purest form and help you stabilizing refactorings and redesigns. Tests that implement use-cases from specs are extremely useful if you work with multiple tiers as they serve as a formalized spec to define and control the interface.
  Not testable = useless: LOL – I think our customers would be happy if we scrap 99% of the application: How do you design a test that shows that a collection of objects is in a consistent state after you applied 10000 transactions on it? How do you test foresight? Most applications I know replace existing systems and are implemented incrementally; the early stages don’t need elements that are crucial for the advanced modules. They cannot be tested efficiently from start, but it is possible to implement them – that’s why you want domain experience. Ignoring this experience becomes a death-kiss to the project, bad thing is that you realize this perhaps two years too late. It is not only the correctness of the code, this is only a necessary (if at all) but not a sufficient condition for a project’s success.

• #10 by anjan bacchu on June 7, 2006 - 3:07 pm

  

  hi cedric,
  a while back, mike spi-lle posted his frustrations on a similar issue — http://www.pyrasun.com/mike/mt/archives/2004/07/10/18.43.16/index.html.
  BR,
  ~A

• #11 by anjan bacchu on June 7, 2006 - 3:13 pm

  

  hi cedric,
  a while back, mike spi-lle posted his frustrations on a similar issue — http://www.pyrasun.com/mike/mt/archives/2004/07/10/18.43.16/index.html.
  BR,
  ~A

• #12 by Don McCaughey on June 7, 2006 - 3:51 pm

  

  I think it’s unfair to say “Very often, Agilists simply forget that their job is to produce software that satisfies customers, not software that meets some golden software engineering scale.” — this is true of all programmers.
  As far as Jeff’s presentation goes, I was also very disappointed. I’m working on a large XP project with a dozen engineers, developing an internal app. Given the title of the talk (“Speeding Up Development With TDD”), I was hoping for more practical information, but unfortunately Jeff’s talk was a sermon aimed at converting the uninitiated.
  As far as Jeff’s two points that bothered you, they bothered me too. I think they are overly simple.
  * Tests are (executable) specs.
  One important principle of agile methodologies is to minimize the amount of low-value work your team does. One very common low-value task is preparing detailed specifications and documentation for an internal system with rapidly changing requirements. Spending hundreds of hours to write and maintain _detailed_ specs and docs for a typical business app, which will be read by an audience in the tens of people, is very low-value work. In this case, a high level overview written in a couple of days will provide a much higher value to the customer.
  However, if you’re Josh Bloch writing libraries for the JDK, then writing detailed specs and docs for an audience of hundreds of thousands of Java developers _is_ high-value work. If your app is part of a drug or medical device manufacturing line, FDA regulations require you to prepare detailed specs, docs and test plans, so it’s also high-value work in this case.
  Very few people like to write documentation, and when they embrace agile, some follow a flawed line of reasoning that goes from “minimize low-value work” to “don’t do detailed documentation” to “your code and tests are your documentation” to “tests are executable specs”.
  * If it’s not testable, it’s useless.
  I’d state this more like, “if it’s not tested, it’s risky”. Developers write tests to verify intent, prevent regression and enable change. If part of your system doesn’t have test coverage, you don’t have direct knowledge that it works as intended, you may change something that causes it to break and not notice right away, and your system becomes harder to change.
  Not writing tests because you have a looming deadline may seem like an acceptable trade-off in the short run if you’re an extraordinary coder whose code always matches their intent (I’m not one), but you leave a bitter legacy for yourself or others who follow when you need to move development forward after the release. Your system regresses more often and the cost of change grows.
  If you’ve worked on an app that has logic in SQL and/or JavaScript, but no test coverage for those parts, you’ve experienced this first hand. The point of agile methodologies is to reduce the risk of change. If you have areas of your system that don’t have automated test coverage, you increase the risk of change and you don’t provide the best value to your customer.
  When you do have an area of your system that isn’t practicable to test, you do your best to isolate it and manage that risk by limiting how your code interacts with it and doing more manual QA targeted at it, if possible.
  That said, an important virtue of developer written tests is parsimony. You should write just enough test code to verify your intent and prevent regression. If you are testing a numerical function (to borrow an example), you don’t need to try and “specify” the formula in your tests by testing every input value, but rather test a few key values to be sure you’re getting correct answers and handling important boundary conditions.
  * The Stack example
  This is a terrible way to illustrate TDD. Particularly since Jeff ended up using a LinkedList as the internal implementation, so that his final Stack implementation was a nearly empty wrapper around LinkedList. (He did emphasize refactoring the test code, which was the one good point I thought he made.)
  I got the feeling that Jeff’s experience with agile development was broad but not very deep — perhaps he’s consulted for a few months at a time with many teams adopting agile methods, but hasn’t worked on any long projects where the team has been committed and skilled users of agile methods.

• #13 by Behrang on June 7, 2006 - 4:21 pm

  

  Wow! A very well written article man! Actually I belive the problem with most advocates of a certain way of thought is hasty generalization and over hyped representation of certain facts. In case of Agilists, Instead of saying “your code would be more usable if it is testable and tested”, they say “If it’s not testable, it’s useless” and so on…
  So far I have only worked in places that claim to follow RUP. Alas I haven’t seen anything RUP in action so far. Just a bunch of useless outdated UML diagrams… Seems RUP is so expensive that cannot be implemented…

• #14 by Behrang on June 7, 2006 - 4:24 pm

  

  Wow! A very well written article man! Actually I belive the problem with most advocates of a certain way of thought is hasty generalization and over hyped representation of certain facts. In case of Agilists, Instead of saying “your code would be more usable if it is testable and tested”, they say “If it’s not testable, it’s useless” and so on…
  So far I have only worked in places that claim to follow RUP. Alas I haven’t seen anything RUP in action so far. Just a bunch of useless outdated UML diagrams… Seems RUP is so expensive that cannot be implemented…

• #15 by Jason on June 7, 2006 - 5:15 pm

  

  Although I agree with a lot of what you say, I think you are perhaps going too far in the other direction when it comes to the claim that “If it’s not testable, it’s useless”. In particular, quotes like this worry me:
  “But the truth is: at times, I don’t do TDD because implementing a feature quickly is more important than a fuzzy feeling.”
  This is at best short-sighted, and at worse a complete fallacy. Certainly, you can knock up the feature code quicker than the feature + test code. Does this mean you have the feature quicker? Maybe … but since you haven’t tested it how will you know? So you might decide to test it by hand … but is this really more efficient than writing an automated test? Particularly as you discover problems and need to retest? Even in this short term view, although counter-intuitive, it may be faster to implement the tests properly.
  In the long term, it is certainly more efficient to have a proper test suite in place. So even if cutting corners helps you get to the deadline faster, the next deadline will surely suffer. You’ll be busy fixing the bugs from the untested code and will have no confidence in new changes made without repeatable tests. Agile or otherwise, all good development teams understand this.
  Pragmatically speaking, there is certainly a threshold where adding more tests will actually start to slow you down. But I think we too easily jump to the conclusion that writing less code in this moment actually saves time, even for short term goals.

• #16 by Jason on June 7, 2006 - 5:24 pm

  

  Although I agree with a lot of what you say, I think you are perhaps going too far in the other direction when it comes to the claim that “If it’s not testable, it’s useless”. In particular, quotes like this worry me:
  “But the truth is: at times, I don’t do TDD because implementing a feature quickly is more important than a fuzzy feeling.”
  This is at best short-sighted, and at worse a complete fallacy. Certainly, you can knock up the feature code quicker than the feature + test code. Does this mean you have the feature quicker? Maybe … but since you haven’t tested it how will you know? So you might decide to test it by hand … but is this really more efficient than writing an automated test? Particularly as you discover problems and need to retest? Even in this short term view, although counter-intuitive, it may be faster to implement the tests properly.
  In the long term, it is certainly more efficient to have a proper test suite in place. So even if cutting corners helps you get to the deadline faster, the next deadline will surely suffer. You’ll be busy fixing the bugs from the untested code and will have no confidence in new changes made without repeatable tests. Agile or otherwise, all good development teams understand this.
  Pragmatically speaking, there is certainly a threshold where adding more tests will actually start to slow you down. But I think we too easily jump to the conclusion that writing less code in this moment actually saves time, even for short term goals.

• #17 by Chui on June 7, 2006 - 7:07 pm

  

  Specs are more than executable tests.
  In any deployed codebase, even unspecified behavior form de facto specification. Witness how MS software breaks whenever they try to change an internal implementation, or how people rely on certain buggy features to perform their work.

• #18 by Hani Suleiman on June 7, 2006 - 8:44 pm

  

  it’s probably no coincedence that many/most agilists (at least,that I know of, they don’t tend to be a closeted species) are consultant types; an environment where maintanability is not an issue, and the fact that it takes a long time to get acquainted is a *good* thing.
  My beef with TDD is that it just doesn’t scale to a real world team. I don’t mean a particularly large one, I mean one with average developers.
  Writing tests first is harder than writing to some spec that someone smarter than you has come up, and most people will botch it up. That relegates it to the realm of ‘neat, but not particularly useful, nor will it catch on in the mainstream’ things, to me.

• #19 by Mishkin Berteig on June 7, 2006 - 9:19 pm

  

  You said: “Let’s talk about TDD for code that interacts with clustered databases on laggy connections built on 500,000 lines of code that was never designed to be tested in the first place”
  Okay!
  Personal Example #1: I used TDD for one part of a very large enterprise framework (don’t know how many kloc, but definitely > 500). The rest of the framework was not built using TDD. My part was the guaranteed delivery messaging system (a JMS implementation to be specific). It was written in Java and used in a large financial institution. When I was finished, it went through QA and Pre-Production testing with zero defects found. It ran in a 2000-server production environment for 2 years before any defects were found. The defect found was a very very obscure deadlocking condition (oh yes, not only was the system a messaging system, but it was also locally multi-threaded).
  Example #2: I used TDD with a small team of 4 developers to build a high-volume multi-processor database-intensive data processing system. The system was smaller in terms of kloc (maybe 20), but again, used in a very serious financial institution. This project used C#/.NET and relied on several non-TTD-friendly external libraries. In this particular institution, this was the first project _ever_ that was delivered on time. TDD and the resulting high quality had a lot to do with it. Although we did find one nasty bug in QA that haunted us a little, it was again a threading/multi-processor related bug. All the business logic was flawless.
  Your objections to TDD and the XP approach also fail to acknowledge the incredible value provided by the management oriented practices of agile methods. Don’t forget that XP isn’t just TDD and pairing. There is also iterative deliver, adaptive planning, user stories, collective code ownership, customer collaboration, etc. etc. etc.
  I happen to be one of those “consultant type” agilists. I focus more on the management and team aspects rather than the techincal aspects (although I come from a techie background). To me, TDD is, as you say, really easy to describe and for anyone with at least one functional neuron, easy to learn. The hard part is doing it consistently and as a discipline.
  Thought-provoking article. Thanks.
  Oh, and if you’re interested, I write about the agile management stuff at http://www.agileadvice.com/.

• #20 by Mishkin Berteig on June 7, 2006 - 9:21 pm

  

  You said: “Let’s talk about TDD for code that interacts with clustered databases on laggy connections built on 500,000 lines of code that was never designed to be tested in the first place”
  Okay!
  Personal Example #1: I used TDD for one part of a very large enterprise framework (don’t know how many kloc, but definitely > 500). The rest of the framework was not built using TDD. My part was the guaranteed delivery messaging system (a JMS implementation to be specific). It was written in Java and used in a large financial institution. When I was finished, it went through QA and Pre-Production testing with zero defects found. It ran in a 2000-server production environment for 2 years before any defects were found. The defect found was a very very obscure deadlocking condition (oh yes, not only was the system a messaging system, but it was also locally multi-threaded).
  Example #2: I used TDD with a small team of 4 developers to build a high-volume multi-processor database-intensive data processing system. The system was smaller in terms of kloc (maybe 20), but again, used in a very serious financial institution. This project used C#/.NET and relied on several non-TTD-friendly external libraries. In this particular institution, this was the first project _ever_ that was delivered on time. TDD and the resulting high quality had a lot to do with it. Although we did find one nasty bug in QA that haunted us a little, it was again a threading/multi-processor related bug. All the business logic was flawless.
  Your objections to TDD and the XP approach also fail to acknowledge the incredible value provided by the management oriented practices of agile methods. Don’t forget that XP isn’t just TDD and pairing. There is also iterative deliver, adaptive planning, user stories, collective code ownership, customer collaboration, etc. etc. etc.
  I happen to be one of those “consultant type” agilists. I focus more on the management and team aspects rather than the techincal aspects (although I come from a techie background). To me, TDD is, as you say, really easy to describe and for anyone with at least one functional neuron, easy to learn. The hard part is doing it consistently and as a discipline.
  Thought-provoking article. Thanks.
  Oh, and if you’re interested, I write about the agile management stuff at http://www.agileadvice.com/.

• #21 by Mishkin Berteig on June 7, 2006 - 9:22 pm

  

  You said: “Let’s talk about TDD for code that interacts with clustered databases on laggy connections built on 500,000 lines of code that was never designed to be tested in the first place”
  Okay!
  Personal Example #1: I used TDD for one part of a very large enterprise framework (don’t know how many kloc, but definitely > 500). The rest of the framework was not built using TDD. My part was the guaranteed delivery messaging system (a JMS implementation to be specific). It was written in Java and used in a large financial institution. When I was finished, it went through QA and Pre-Production testing with zero defects found. It ran in a 2000-server production environment for 2 years before any defects were found. The defect found was a very very obscure deadlocking condition (oh yes, not only was the system a messaging system, but it was also locally multi-threaded).
  Example #2: I used TDD with a small team of 4 developers to build a high-volume multi-processor database-intensive data processing system. The system was smaller in terms of kloc (maybe 20), but again, used in a very serious financial institution. This project used C#/.NET and relied on several non-TTD-friendly external libraries. In this particular institution, this was the first project _ever_ that was delivered on time. TDD and the resulting high quality had a lot to do with it. Although we did find one nasty bug in QA that haunted us a little, it was again a threading/multi-processor related bug. All the business logic was flawless.
  Your objections to TDD and the XP approach also fail to acknowledge the incredible value provided by the management oriented practices of agile methods. Don’t forget that XP isn’t just TDD and pairing. There is also iterative deliver, adaptive planning, user stories, collective code ownership, customer collaboration, etc. etc. etc.
  I happen to be one of those “consultant type” agilists. I focus more on the management and team aspects rather than the techincal aspects (although I come from a techie background). To me, TDD is, as you say, really easy to describe and for anyone with at least one functional neuron, easy to learn. The hard part is doing it consistently and as a discipline.
  Thought-provoking article. Thanks.
  Oh, and if you’re interested, I write about the agile management stuff at http://www.agileadvice.com/.

• #22 by Kamal on June 7, 2006 - 10:35 pm

  

  I think this article was written in haste, provoked by a single (few) incident(s). Coming from people like you it will do a lot of harm.
  It is wrong to generalize the attitude of a few and blame the whole agile crowd.
  Every technology / methodology has its own share of zealots. People who think they are doing it but arent really doing it right.
  I have been attracted to the agile practices mainly because of the pragmatic approach and the emphasis on delivering value to the customers. Over the past few years I have spent a lot of time reading what people like Dave Thomas, Andy Hunt, Robert Martin, Craig Larman, Ron Jeffries, Martin Fowler, Michael Feathers have written. The more I read and more I think about it I am convinced that for projects to be successful they need to adopt some of these practices.
  There are people who are making an attempt to go beyond the toy problems and show you how to apply these practices. One good example is this book
  Working Effectively with Legacy Code
  http://www.amazon.com/gp/product/0131177052/104-6025377-3148732?v=glance&n=283155
  Most of the popular open source projects are proof that you can deliver successful software without specs. I have never come across a requirement spec or design spec for things like hibernate, springframework. I have even come across a number of cases where people are being refered to tests to understand how something works where there was inadequate user documentation.
  Hope you will reflect on it a bit more.

• #23 by Tim Vernum on June 8, 2006 - 12:51 am

  

  > but is this really more efficient than writing an automated test?
  TDD != Automated Testing
  TDD implies writing the tests first and then the code. (Often it implies 1 test, then a small amount of code, then another test, then more code…)
  It may or may not be a good way to get well designed code. It’s definately not the _only_ way to get well designed code. And it’s not the _best_ way in _every_ situation.
  The software game is about products, not processes. Good processes help produce good products. Automated testing is a good process.
  That’s about as strict a set of statements as we can make.
  If you want to say that “the quality of the processes are the sole determinant of the quality of the product” or “automated testing is the best process” then you’re engaging in unnecesary (and dishonest) hyperbole.

• #24 by Lee Meador on June 8, 2006 - 8:29 am

  

  Saying “tests can have bugs” is misleading and not useful to the issue of whether tests can be specs. Any sort of specs can have mistakes. A bug is just what we call a mistake in the code.
  You could specify that the name be shown as “Last, First” but if that isn’t correct …

• #25 by Daniel Serodio on June 8, 2006 - 9:46 am

  

  IMHO, that’s what the “Extreme” in “Extreme Programming” means: shocking people. XP is not really extreme, but its proponents are always trying to shock their audience.
  Shocking the audience can have 2 opposite effects: either they’ll think “wow, I’d never thought about this before, let’s listen to what this guy is saying”, or “this guy is full of s***, let’s get back to work”.
  I really like TDD, but if I heard “if it’s not testable, it’s useless”, I’d go back to “the real world” and work.
  I prefer the motto “if it’s not testable, it’s detestable”.
  And this “if didn’t work for you it’s because you didn’t follow it properly” excuse is really lame and old.

• #26 by sammy on June 8, 2006 - 11:39 am

  

  I’m going to speak out in defense of Sam, the first commenter, and not just because we share a first name.
  In your post, you lambast Agile developers for using “useless” examples in classroom settings like “let’s code a Stack.”
  When Sam claimed to have worked on a project of signifigant size and that he used XP successfully on it, mmatt criticized him for “putting himself on a pedestal.”
  So in other words, demonstrating that it works in a small case is useless, while claiming that it works in a large case is bragging. With standards like that, it’s no wonder noone can prove to you guys that agile software methods are effective.
  (Disclaimer: I don’t even particularly like “agile methodology” beyond the continuous integration and rigorous testing aspects.)

• #27 by sammy on June 8, 2006 - 11:40 am

  

  I’m going to speak out in defense of Sam, the first commenter, and not just because we share a first name.
  In your post, you lambast Agile developers for using “useless” examples in classroom settings like “let’s code a Stack.”
  When Sam claimed to have worked on a project of signifigant size and that he used XP successfully on it, mmatt criticized him for “putting himself on a pedestal.”
  So in other words, demonstrating that it works in a small case is useless, while claiming that it works in a large case is bragging. With standards like that, it’s no wonder noone can prove to you guys that agile software methods are effective.
  (Disclaimer: I don’t even particularly like “agile methodology” beyond the continuous integration and rigorous testing aspects.)

• #28 by Daniel Serodio on June 8, 2006 - 1:01 pm

  

  The point is that Sam failed to mention any number about the “*real* project”. How many people/classes/LoCs/months ? Anything?
  Without numbers, we can only assume that he is bragging.

• #29 by Marcus Widerberg on June 8, 2006 - 4:39 pm

  

  This was so stupid it hurts! I want my minutes back!

• #30 by Thiago Arrais on June 8, 2006 - 7:42 pm

  

  Tests certainly aren’t specs, but they are executable. That’s what makes them so useful, they provide very fast feedback. And that’s the whole point behind this agile thing: reducing the time for feedback by means of highly iterative practices.

• #31 by Bruce T on June 8, 2006 - 10:09 pm

  

  Nice blog in some ways, but paints with much too broad a brush. See my comments at [paddle like hell](http://blog.rapidred.com/articles/2006/06/09/people-who-generalize-suck.)

• #32 by Anonymous on June 9, 2006 - 6:06 am

  

  First off, I respect you for standing up to the agile religion, it’s like scientology or something… Personally, I’ve been fearful of speaking strongly against agile, even though that means watching US engineering continue to spiral down the toilet. It’s funny because we have 50 years of engineering software experience that shows us how most of these agile practices don’t effectively work.
  There are a couple things, first tests and TDD are nice but there are costs and as the project grows the whole process has to slow down because tests balloon the code base (it’s usually worth while) but I’ve seen more than a few cases where these simple quick deep changes resulted in retooling hundreds of testcases. The more test coverage you get, ironically, the less quickly you can do certain things but you end up with more trust in those things.
  Also, there are problem spaces where agile just doesn’t work. Most agilists tend to be web developers or consultants. If a web page is a “work item” then agile is beautiful or if you don’t plan on being there when/should they get to the finish line then agile might work for you. There are no embedded agilists. There are no system agilists. You don’t evolve a design like TCP’s. So long as your goal is to simply use technology and not provide any, agile might work just pick Rails or Jboss off the shelf and build a website on top of it and iterate on the look and feel and you’ll be super agile. Does a bank want monthly releases? Secondly, when you sell to customers like banks the weight of releases increases, you simply cannot “reset them” or screw up a release after they are deployed. I know that’s a problem that should be addressed but it is a constantly moving target in many cases, it’s not a fix it and forget it problem, not unless you’re making a little piece of software.

• #33 by Dave C on June 9, 2006 - 6:29 am

  

  Ah…the backlash.
  As a long-time “real world” agile practitioner (not as a consultant), let me chime in.
  Practices are not the same as principles. The definition of “Agile” is not TDD + CI + PairProgramming + IndexCards = Success
  Software development is ENTIRELY about the people working on a project, and their ability to adapt to what’s happening. In my mind, this adaptation is the core of agility.
  In my own experience as a developer and dev manager, I was unable to use the exact same Agile approach on different projects. I had to tune it for the situation, sometimes adding practices, sometimes eliminating them.
  So to me this means that anyone claiming that a single set of practices is the One True Way ™ is probably selling something or just inexperienced.
  Having said that, there are practices that seem to have universal value, agile or not. I happen to think automated tests are a good thing, whether they are done first or last.
  From a project management standpoint, short iterations and frequent delivery to the customer have been invaluable to me.
  Your mileage may vary, but let’s not paint everyone who believes in Agile approaches as a lunatic. But I understand the source of this rant.

• #34 by Dave C on June 9, 2006 - 6:30 am

  

  Ah…the backlash.
  As a long-time “real world” agile practitioner (not as a consultant), let me chime in.
  Practices are not the same as principles. The definition of “Agile” is not TDD + CI + PairProgramming + IndexCards = Success
  Software development is ENTIRELY about the people working on a project, and their ability to adapt to what’s happening. In my mind, this adaptation is the core of agility.
  In my own experience as a developer and dev manager, I was unable to use the exact same Agile approach on different projects. I had to tune it for the situation, sometimes adding practices, sometimes eliminating them.
  So to me this means that anyone claiming that a single set of practices is the One True Way ™ is probably selling something or just inexperienced.
  Having said that, there are practices that seem to have universal value, agile or not. I happen to think automated tests are a good thing, whether they are done first or last.
  From a project management standpoint, short iterations and frequent delivery to the customer have been invaluable to me.
  Your mileage may vary, but let’s not paint everyone who believes in Agile approaches as a lunatic. But I understand the source of this rant.

• #35 by Emmanuel Pirsch on June 9, 2006 - 7:02 am

  

  Here is my take on the matter : http://epirsch.blogspot.com/2006/06/agility-is-about-customer.html

• #36 by Julio on June 9, 2006 - 7:23 am

  

  > They offer you all these nice ideas such as Test-Driven Development and Pair Programming but they never — ever — disclose the risks and the downsides. To them, Agility is a silver bullet that is applicable in all cases with no compromises.
  You couldn’t have more dishonest (or ignorant of agile communities)

• #37 by Chris on June 9, 2006 - 7:46 am

  

  The “Agile Thugz” comment is the funniest thing I’ve read in a while. Fuh’real Fuh’real, word to my muva.

• #38 by Kane on June 9, 2006 - 10:18 am

  

  You pose a good problem when you asked: “How do you specify an exponential function with a test?” This doesn’t directly answer you question, but I thought your audience might be interested:
  http://www.extremeperl.org/bk/test-driven-design

• #39 by Muk on June 9, 2006 - 11:09 am

  

  Well – this has been bothering me for sometime so I think I will come clean. There are things about TDD that lend themselves well to certain forms of development like POJO/framework development. Java development that depend on Enterprise infrastructure do not lend themselves well. So at that point do what is pragmatic and test what pieces you can.
  Documenting code certainly has merits and the flip side is true as well – it is more likely to get out of whack. Larger software teams will not
  lend themselves to agile and if “time to market”
  is critical – which is the case with most professional companies you cannot TDD fully.
  So I see Cedric’s points. I have yet to follow any methodology fully on a project without improvising and see it work. You see, evaluate, adopt what works well and move on…

• #40 by Anonymous on June 9, 2006 - 2:54 pm

  

  I’m not going to bother to defend my post because it’s pointless. There will always be some BS excuse about how my particular situation was unique in some way that made it possible.
  I’m only posting to say that most people I run into don’t really believe in Agile development. They may think there’s a few good things in there to learn from but overall it’s just “pie in the sky” bullshit. Consequently, there are very, very, very few Agile projects actually in existence. As a consultant I get to work around at a lot of different companies. And even with that going for me, the odds of me getting to work on more Agile projects as time goes on is close to zero.
  So don’t worry Agile haters. It’s more of a neat idea. You’re all perfectly safe in your little worlds that you guard so carefully. In the end it doesn’t matter to me. I get paid the same amount whether the processes I use are retarded or brilliant.

• #41 by Muthu Ramadoss on June 9, 2006 - 9:59 pm

  

  You CANNOT do AGILE in India. Period.
  If you want to, you need to join Thoughtworks, India.
  I am saying the above considering the practical realities of Software Development in India.
  Muthu Ramadoss.
  http://groups.google.com/group/etoe

• #42 by Muthu Ramadoss on June 9, 2006 - 10:00 pm

  

  You CANNOT do AGILE in India. Period.
  If you want to, you need to join Thoughtworks, India.
  I am saying the above considering the practical realities of Software Development in India.
  Muthu Ramadoss.
  http://groups.google.com/group/etoe

• #43 by Anonymous on June 10, 2006 - 8:33 am

  

  I think if you use Scrum you do alleviate some of your concerns about the spec. Actually the spec quality can increase since the product team can continue refining the product backlog during the sprint (the items that are not contained in the sprint backlog).

• #44 by Anonymous on June 10, 2006 - 8:33 am

  

  I think if you use Scrum you do alleviate some of your concerns about the spec. Actually the spec quality can increase since the product team can continue refining the product backlog during the sprint (the items that are not contained in the sprint backlog).

• #45 by Anurag Shrivastava on June 11, 2006 - 11:34 pm

  

  You can do Agile in North India for sure. Xebia, a subsidiary of Xebia IT Architects B.V. in Holland, is a software house specializing in Agile and Iterative methodologies. We have a working offshore Agile Development Practice. I will be interested in getting touch with people who would like to share their Agile experience on Java/J2EE based projects.
  Anurag

• #46 by Anurag Shrivastava on June 11, 2006 - 11:35 pm

  

  You can do Agile in North India for sure. Xebia, a subsidiary of Xebia IT Architects B.V. in Holland, is a software house specializing in Agile and Iterative methodologies. We have a working offshore Agile Development Practice. I will be interested in getting in touch with the people who would like to share their Agile experience on Java/J2EE based projects.
  Anurag

• #47 by Robert C. Martin on June 12, 2006 - 6:02 am

  

  I have responded to this on:
  http://butunclebob.com/ArticleS.UncleBob.AgilePeopleStillDontGetIt

• #48 by Michael Feathers on June 12, 2006 - 6:37 am

  

  Cedric said: >>>To be honest, I am becoming quite suspicious of Agile practices for that reason: all the presentations I have attended and books that I have read are always using toy implementations as examples. Stack, List, Money, Bowling… enough already! Let’s talk about TDD for code that interacts with clustered databases on laggy connections built on 500,000 lines of code that was never designed to be tested in the first place (and: yes, I read Michael Feathers’ book, it has some good and some bad, but it’s not germane to Java and TDD so I won’t expand on it here).<<<
  Are you serious? Well over half of the examples are in Java, and yes it is TDD: you get the test around the code you want to change first.
  Re presentations about TDD. I share your concern, but frankly, I do exactly the same thing that Jeff did most of the time. Whenever you’re presenting something you have to figure out what to leave out so that people aren’t swamped with irrelevant detail; so that they can see the forest for the trees. I call it ‘pedagogical challenge’ and it’s a pain. You’ll always find people who won’t think it’s real to them unless the example resonates with some aspect of their personal experience, but you try to reach who you can and often that means picking something non domain-specific so that everyone can engage.
  The fact is, TDD is pretty independent of context. Name a class that is supposed to work in your “clustered databases on laggy connections built on 500,000 lines of code that was never designed to be tested in the first place.” If we paired together, we’d do the same thing that we would do with bowling or a stack. They are the same steps, really. We’d figure out what logic we need, and we’d develop it test first, independently of all the other crap, in a test harness. It takes work to get people to get that.. that it’s all about building things independently.
  ‘Working Effectively in Legacy Code’ can really be seen as a cautionary tale. That’s what you have to go through when your code wasn’t designed for test. I’m not one of those who tell people “if you used TDD you wouldn’t be in this mess” but I do imply it and I help them discover it. In fact, my favorite coaching technique right now is to help groups start to use TDD on the easy bits, the new features that look like they can be independent and they discover how it makes development easier. Then we go in and try to change existing code.. we notice that we’re not really sure of our changes like we were in the TDDed code. But we want to be sure so we go in and do all sorts of tricky work to get tests in place. It is tricky work and it is a pain in the ass. And, that’s usually enough to sell people. If you’ve worked in a good TDDed code base and you do the latter work often enough, you realize just how insane it is not to TDD from the beginning and it is hard to bite your tongue and not give that message to people who aren’t prepared for it. But giving them the experience does help.

• #49 by Brad Appleton on June 12, 2006 - 8:21 am

  

  I happen to be a person who works in a large telecom company on large projects that has been adopting and adapting agile methods over the past 5 years with stellar improvements in quality, productivity and cycle-time as the fruits of our labors. Our organization consists of many thousands of people across several divisions, each of which works on one or more systems with hundreds of engineers, tens of millions of lines of code, with subsystems in the 1M+ line of code range, and components in the 100K+ line of code range.
  My first comment would be that Cedric’s post seems specific to XP, rather than all (or even most) agile methods. Take a look at Feature-Driven Development or FDD (http://www.featuredrivendevelopment.org/), which is quite different from XP and has none of the things that Cedric is complaining about.
  Secondly, I can say that much of what Cedric says rings both true *and* false in my organizations adapting of Agile methods to our large projects. Our tailored Agile method combines elements of XP, Scrum, FDD, and traditional systems engineering. On the surface it bears the most resemblance to a mix of systems engineering and XP.
  We adopted practices like TDD, CI, Refactoring, Pairing, “Simple” Design, and a few others. However we also still do plenty of requirements documentation, we use formal tracking systems for managing change-requests and problem-reports, we make use of model-driven development, and we do comment our code and write high-level architecture/design docs (but much more lightweight than before — trying to stick to high-level information that spans more than one file/class of a component).
  Agile doption in the company has been progressing slowly but surely. We definitely run into skeptics; The most compelling persuasion for our skeptics is successful real-world results with measurable improvement in each area claimed. It works most effectively when the skeptics participate in the success 🙂

• #50 by Jeff Langr on June 12, 2006 - 4:36 pm

  

  Greetings Cedric,
  It’s a long blog posting, and I just wanted to comment on a few errors you made.
  1. “tests are specs” is a mindset, a generalization, and I made this point clear when Bloch (I think) challenged it. In fact, that was the title of the slide as presented: “Mindsets”. It helps to recognize the idea of treating these as specs, because most people doing TDD do a poor job of coding them to be readable.
  2. “If it’s not testable, it’s useless” was on the same slide, about mindsets. Both of these are attitudes. The more people move in the direction of these attitudes, the better. There are always exceptions.
  I even said that these were things that helped me think in terms of how I want to approach TDD.
  3. No, “we” do *not* get TDD. Most people don’t. Most developers doing it based on reading the 30 second blurb do it poorly. Then they grouse, like you do, that it’s not all testable. Usually, the inability to test close to 95% or more of your app suggests you have a bad design.
  4. “How about: if we pop an empty stack, we get an exception”
  “Mmh, no, let’s not do that”
  You did not hear my response to this. I suggested that popping from the empty stack doesn’t have anything to do with “testCreate” for a stack. Which it doesn’t–it’s separate behavior. It’s on the tape, if you wanted to watch it again.
  5. “Well, if you had started with TDD in the first place, you wouldn’t be having this problem today”.
  I even admitted this was a glib answer and suggested why.
  I’m pretty disgusted with the way you’ve misrepresented my talk. I think you’re the one who’s being dishonest, Cedric.
  —
  I was invited to google to speak with the understanding that the audience was interested in an introductory level discussion. Hence the simplistic example, and also hence my emphasis on technique. My apologies that it didn’t get communicated that way. Frankly, I find the fact that you suggest that I was being dishonest slanderous and ultimately just disappointing.
  I don’t work on open source. I work with real customers, most of them Fortune 500, who have far worse code than they need to have. I’m currently working with one customer who took 190,000 lines of code 9 sprints ago, and reduced it to 60,000 since then, all along adding new features. They did this by virtue of doing TDD the “right” way. Not by making excuses about why they couldn’t test it all.
  I’ve been excited about working with companies and doing TDD, because I’ve seen it work when done well, and I’ve seen the dramatic decreases in cost. So here’s my advice to you, Cedric, and to Google: you can stay on your high horse and post misleading comments. I’m just going to keep doing what I know can work well.

• #51 by Danno on June 12, 2006 - 9:11 pm

  

  I won’t claim to be an expert or anything, or to be all that good at doing TDD.
  But I will say that on the small set of projects that I’ve done in my time as a student, when we were able to test, things went swimmingly and smoothly and shit got done very, very fast.
  When we couldn’t test something (Like a GUI, we didn’t know how, really), or there just wasn’t enough time to test, things got really, really bad very quickly.
  I’m not gonna say that my experience is a rule, but I don’t like coding without a safety net of tests anymore. I don’t think I’m good enough to do it.

• #52 by FreeThinker on June 13, 2006 - 8:08 am

  

  Open your mind friend… What you are speaking of sounds a little like stumbling around in the dark with a map…
  Question:
  How do you specify an exponentiation function with a test?
  Answer:
  Use a known value… run the function and assert that the output matches the known value…
  Although most people don’t test the compiler, lol…

• #53 by loosenut on June 13, 2006 - 9:00 am

  

  Anyone have a link to the video of the talk?

• #54 by FreeThinker on June 13, 2006 - 9:02 am

  

  “enough already! Let’s talk about TDD for code that interacts with clustered databases on laggy connections built on 500,000 lines of code that was never designed to be tested in the first place”
  Ok… Think of the code you normally write…
  Now… Add tests to verify that it actually works the way you think it does… How is thier any less value?
  I mean tests help with:
  Debugging… Immediate notification of where in the production code the problem is…
  Remembering… What the heck was I thinking 2 years ago?
  Changing… Ok, If i make this change I will break… Yep thats what I though…
  Designing… Wow, that is totally going to suck, but if I abstract this and that… Ok, here is the test… Ok, Here is the code… Ok, it works… next feature…
  Personally I don’t want to wade through 500,000 lines of code unless I absolutely have to… You go right ahead and guess what to fix when it breaks… I will let the tests tell me…

• #55 by theory versus practice on June 13, 2006 - 9:51 am

  

  XP, in practice, is about pairing incompetent programmers with competent ones. So the managers of these programmers can have larger teams to justify their bloated programmer/manager salaries (not to mention satisfy Equal oppurtunity laws and such).
  Competent programmers make code that works suitable to the users’ needs.

• #56 by Reason of Reason on June 13, 2006 - 11:37 am

  

  The truth is, that it doesn’t matter which style of programming you choose. If your a good programmer it’ll change from project to project anyway. The whole belief in Agile programming is no different than MAC vs. PC in that each company and person makes a choice. If you are truly an intelligent person than you’ll pull from all technologies. Some projects just need code and testing and code and testing, etc. But others can’t be tested in all scenerios becuase there are too many to test. But I do feel as though I need to say that if you believe that Agile programming is the only way to program than you are ignorant and should move on to something like knitting, the same to the people who think that Agile programming should never be used.

• #57 by Anon on June 13, 2006 - 11:54 am

  

  Bravo for questioning the religion. I would rather question Scientology to Tom Cruise than try to take some of these Test Driven Development people on in a debate. Anyone outside of the deepest tech niches sees that phrase and things… why are tests driving development? What do tests have to do with me making money via technology? And how did 50 years of tech get built without TDD… I guess, according to these people, all that old code must be crap!
  The biggest affront to reality that TDD brings forth is that tests should be the focus. They are important – but TDD is one of the biggest tail wagging the doggisms I can think of.
  BTW, your project sponsor might want a spec. Test code is not likely to be something that the legal department that is seeing whether you have met the spec at project end wants to use. Most corporate counsel don’t read Java or C#.

• #58 by Anon on June 13, 2006 - 11:54 am

  

  Bravo for questioning the religion. I would rather question Scientology to Tom Cruise than try to take some of these Test Driven Development people on in a debate. Anyone outside of the deepest tech niches sees that phrase and things… why are tests driving development? What do tests have to do with me making money via technology? And how did 50 years of tech get built without TDD… I guess, according to these people, all that old code must be crap!
  The biggest affront to reality that TDD brings forth is that tests should be the focus. They are important – but TDD is one of the biggest tail wagging the doggisms I can think of.
  BTW, your project sponsor might want a spec. Test code is not likely to be something that the legal department that is seeing whether you have met the spec at project end wants to use. Most corporate counsel don’t read Java or C#.

• #59 by FreeThinker on June 13, 2006 - 2:11 pm

  

  This is the more one sided view I have ever seen…
  I’ve never worked on a “real” Agile project, but I do know one thing – Agile isn’t a panacea, not even close. I work on a project that *can’t* be Agile. We have hundreds of developers spanning dozens of different companies and divisions. Many of the things I’ve seen Agilists attribute to themselves (lots of tests, good customer interaction) are more the hallmarks of a good team, rather than methodology.
  Every thing I have ever read about agile has stated is was not a panacea… What the heck did you read buddy…
  OBVIOUSLY YOU MUST HAVE ONLY READ THE FIRST CHAPTER OF WHATEVER IT WAS…
  Every Project has work that can not be agile, but that does not mean because it does not fit every scenario you throw it out the window or it does not add value…
  Don’t be a dork… If you are set in your ways and don’t wanna learn what its all about – and dont give me that “I READ THE BOOK CRAP”
  Don’t slam the rest of us for trying to better ourselves and the community…

• #60 by Anonymous on June 13, 2006 - 2:12 pm

  

  This is the more one sided view I have ever seen…
  I’ve never worked on a “real” Agile project, but I do know one thing – Agile isn’t a panacea, not even close. I work on a project that *can’t* be Agile. We have hundreds of developers spanning dozens of different companies and divisions. Many of the things I’ve seen Agilists attribute to themselves (lots of tests, good customer interaction) are more the hallmarks of a good team, rather than methodology.
  Every thing I have ever read about agile has stated is was not a panacea… What the heck did you read buddy…
  OBVIOUSLY YOU MUST HAVE ONLY READ THE FIRST CHAPTER OF WHATEVER IT WAS…
  Every Project has work that can not be agile, but that does not mean because it does not fit every scenario you throw it out the window or it does not add value…
  Don’t be a dork… If you are set in your ways and don’t wanna learn what its all about – and dont give me that “I READ THE BOOK CRAP”
  Don’t slam the rest of us for trying to better ourselves and the community…

• #61 by FreeThinker on June 13, 2006 - 3:15 pm

  

  I see this over and over in your posts Cedric…
  I often wonder if any of the XP people have ever in their lives worked on an application with more than 30,000 lines of code.
  I have… For fun…
  So what if you wade through lots of code…
  So what if you think XP will not work on huge projects… You are wrong!
  Maybe XP will not work on my projects is a more accurate statement…. Because obviously you are opposed to anything agile and unwilling and or unable to get it…

• #62 by Frank Bolander on June 13, 2006 - 3:49 pm

  

  Jeez,
  Methinks you’ve hit a nerve,Cedric.
  I have worked on 3 large “Agile” projects, two run by different “agile” guru shops(even mentioned in these posts) and one was a hybrid. The hybrid one was a success but the other two were disasters. For being so agile, these methodologies don’t exactly lend themselves to change or even open to input outside the “agile box”. It’s a feast or famine mentality and when things do go wrong it’s the old “it was done wrong” or “old methodology ruined it” blame game even though these agile groups managed the process. For one, the gurus’ process definitions didn’t even match in their dictionaries. These Agile gurus end up being self-serving poets rather than technologists and engineers.
  And the whole “I’ve used TDD used right and it was a success, you must be doing it wrong” strawman argument just pisses me off. Big focking deal. If a process isn’t reproducible across variations in conditions, it’s just mental masturbation. Any process should work if it’s used correctly, a better metric would be how well a process methodology adapts which, contrary to all the hype, agile methods don’t do very easily in real situations. A case in point is offshoring. More time, effort and resources are wasted trying to hammer a round peg in a square hole than admit a deficiency and adapt to the reality. Let’s not forget there were a lot of software projects over the decades that were successes without “agile” methodologies. The “Agilists” make it seem like all projects, except theirs of course, are failures.
  Finally, TDD is just one aspect of agile, why is it the only one emphasized in every argument? I do believe in agile overall, but I have to agree with Cedric. It’s turning into a narrow minded religion instead of a toolkit. And it has been sold as a panacea by vendors and Agile consultants so I’ll have to disagree with some of the previous posters also.

• #63 by Steve Conover on June 13, 2006 - 4:41 pm

  

  Cedric,
  You (and Dave C — great post) make one very important point that we Agile proponents should repeat over and over again to ourselves:
  “Very often, Agilists simply forget that their job is to produce software that satisfies customers, not software that meets some golden software engineering scale.”
  Agile isn’t the end, the software *product* is. Agile practices are *tools* that interact together to help us achieve the goal. Again, other than in conferences, the goal is not to do Agile.
  However you go way too far in discounting TDD (it’s bizarre to me that you drop it under pressure). You shouldn’t do TDD because it’s a “good idea” or “correct” in the abstract, you should do it because it helps you. Every time I deviate, or I see teams deviate from TDD’ing they more than make up for it in debugging time. And there’s no nice regression suite left in their wake.
  The higher-pressure the siutation, the more pressure I feel to test-drive. I need the quick incremental feedback. I can’t afford to waste time wondering if what I just wrote actually works, and spending time figuring it out in “big bang” integration.
  About large projects: I’ve been directly involved in and continue to be associated with people who are doing Agile at the most prominent internet companies you can name. There are techniques you can use to hive off critical portions of the project and just do Agile there, etc. But I’ve both done it and seen it done successfully – in some cases spectacularly well.
  (I’ve seen it fail too – it can’t be emphasized enough that getting your engineering house in order is just one part of the software product equation – Agile engineers, like most engineers, tend to be too heads-down in this respect IMHO).

• #64 by Kevin Taylor on June 13, 2006 - 6:48 pm

  

  Real Agile developers deliver value. See my complete response: http://java.about.com/b/a/256853.htm

• #65 by Erik on June 14, 2006 - 5:45 am

  

  Cedric – I fear you’re the one who doesn’t (want to?) get it.
  You are certainly right when you state that Agility is no silver bullet – there will never be one anyway, so that’s not the issue.
  From my experience the “real software world” badly needs agility. Far too much untested (and therefore sometimes hardly usable) software is released every day. The real risk is already there – and so are the real costs of sofware that doesn’t work as it should. For sure you can overdo everything and fail by applying blindly a recipe – but agility is also fundamentally about empowering the team and have it take responsibility for the project (choosing the methodology etc.). So the team must learn modern development techniques – and TDD is one of those – and then choose what’s best here and now to deliver the software with the required functionality and quality at a given date.
  Your blog is therefore blind on one eye and provides pseudo arguments to those who reject agile methods because they think it is BAD(TM) or just a hype or because it didn’t work for them the first time (maybe training the team a bit more or really empowering it would have helped) or it would cost too much etc.
  I would certainly not recommend to believe everything consultants tell you (whether they advocate agility, RUP, MDD etc.) but I really think you should honestly try it and pick what’s good for you – and my experience is that agility brings a lot that’s good and effective.

• #66 by Phran on June 14, 2006 - 6:19 am

  

  I like Test-Driven Development. I really do, and I’m fortunate enough to work on a project that lets me use TDD most of the time. But the truth is: at times, I don’t do TDD because implementing a feature quickly is more important than a fuzzy feeling.
  And you do that because you are in your nature agile. You do what you think provides most value at that point

• #67 by test on June 14, 2006 - 8:58 am

  

  test

• #68 by Hans on June 14, 2006 - 2:20 pm

  

  I think Jeff, Michael, and Robert have shown well that Cedric (once again?) doesn’t know what he’s talking about, or at the least, talks without thinking first.
  The quality of this blog software is probably a good example of following Cedric’s “calculated risk” approach to development. I think Cedric would be more honest to call his style “faith based software development”.

• #69 by Colonel Nikolai on June 15, 2006 - 10:12 am

  

  Bad presentation aside, I’ve done both XP and what I refer to as basically “everything else”, which whether it is being hailed as CMM processes (PSP/TSP) or not, they basically come down to hacking (or “code-and-fix-and-fix-and-fix”) methodologies. I have found that it is much better to work on an XP project than the other kind by a wide margin.
  The best thing I can say about it is “XP is better than not”. It is not a silver bullet.
  I have worked at places like you describe where Agile is very difficult because doing a good job is very difficult because everyone is used to doing a poor job and calling it OK. An XP environment causes the bad stuff to come up much faster because it forces people to face reality much sooner. EVERYONE, even customers are forced to recognize where things aren’t working. This is the key.
  Sometimes is easier if we just don’t do Agile because nobody wants to admit that what they’ve done is crap, all up and down the ladder. So Agile “fails” in this case.
  Which brings me to this question: is it better to have a project fail quickly or fail after several million dollars have been blown? XP will fail faster because it assumes the answer is failing quickly is preferable. Everything else comes from there.

• #70 by Michael Bolton on June 15, 2006 - 7:12 pm

  

  As a trainer of testers, I have some sympathy for the complications imposed by the classroom situation. I heard from Cem Kaner (he may or may not have originated the saying), “Toy problems teach contempt for both the problem and the solution.” One of our goals as trainers and advocates of the things that we believe in, should be to work relentlessly at developing exercises that are sufficiently challenging for the skeptics and sufficiently feasible for the novices and the time constraints. That’s a big challenge for us.
  I don’t have a whole lot of respect for the extremists (note the absence of a capital) on either side of this debate. What impresses me about this discussion is how, for both sides, it centres around processes and tools and following a plan, and downplays the significance of people and interactions and adapting to change. That is, I don’t think it’s a very Agile discussion. Moreover, it’s sadly typical of spirited debates about Agility.
  I’d like to suggest that we could make some sense of it all by going back to the Agile (http://www.agilealliance.com/intro) and Context-Driven http://www.context-driven-testing.com/) Principles , and thinking hard about both lists–in particular, the point in the Context-Driven principles that people, working together, are the most important part of any project’s context.
  I’ve seen some remarkable things done very quickly and efficiently with lots of approaches, some Agile, some not. What the successful projects have had in common is this: smart people of good will, working together thoughtfully. Some practices may be helpful, but if they’re implemented poorly by the wrong people, the practices will eventually be perverted into some new way of going through the motions.
  I like TDD. I like lots of programmer tests. I like refactoring to make the code more readable (to /people/). I like the XP practices. I like the humanism implicit in the Agile Manifesto more, though. In general, I’d like to see a little more attention paid to the items on the left.
  —Michael B.

• #71 by Michael Bolton on June 15, 2006 - 7:12 pm

  

  As a trainer of testers, I have some sympathy for the complications imposed by the classroom situation. I heard from Cem Kaner (he may or may not have originated the saying), “Toy problems teach contempt for both the problem and the solution.” One of our goals as trainers and advocates of the things that we believe in, should be to work relentlessly at developing exercises that are sufficiently challenging for the skeptics and sufficiently feasible for the novices and the time constraints. That’s a big challenge for us.
  I don’t have a whole lot of respect for the extremists (note the absence of a capital) on either side of this debate. What impresses me about this discussion is how, for both sides, it centres around processes and tools and following a plan, and downplays the significance of people and interactions and adapting to change. That is, I don’t think it’s a very Agile discussion. Moreover, it’s sadly typical of spirited debates about Agility.
  I’d like to suggest that we could make some sense of it all by going back to the Agile (http://www.agilealliance.com/intro) and Context-Driven http://www.context-driven-testing.com/) Principles , and thinking hard about both lists–in particular, the point in the Context-Driven principles that people, working together, are the most important part of any project’s context.
  I’ve seen some remarkable things done very quickly and efficiently with lots of approaches, some Agile, some not. What the successful projects have had in common is this: smart people of good will, working together thoughtfully. Some practices may be helpful, but if they’re implemented poorly by the wrong people, the practices will eventually be perverted into some new way of going through the motions.
  I like TDD. I like lots of programmer tests. I like refactoring to make the code more readable (to /people/). I like the XP practices. I like the humanism implicit in the Agile Manifesto more, though. In general, I’d like to see a little more attention paid to the items on the left.
  —Michael B.

• #72 by mq on June 16, 2006 - 3:55 am

  

  I had somewhat similar experience of sitting through a presentation by 3 Agile proponents. It quickly became obvious that biggest project they worked on had 3 developers and was fairly mickey-mouse standalone application. It was like being at some religious ceremony; if you questioned anything you were dismissed as unbeliever who’d soon be in hell (unemployable). One of they’re cool ideas was a flashing screen in bright colors everytime continuous build broke and somehow was ‘coolly’ delivered to all dev desktops (not sure if this was they’re own extension to Agile that they hoped to patent and make millions from, but they were very excited about this). ‘Ok, so I’ve got 50 developers who gets this flashing notification of build failure, how does that help productivity?’ The reply ‘It’ll get fixed real fast’. Sure, and they’ll be no build failures for a few hours as everyone goes into a tizzy trying to fix build (or maybe everyone ignores, the process only had been scaled to 3 developers so presenter wasn’t too forthcoming with how it would scale).
  Annoyingly they even did lot of presentation using pair-presenting; just appeared to be talking off differnet scripts:-)
  I’m not anti-agile; just anti brain dead quasi-religious fanatism.
  mq

• #73 by Joel on June 16, 2006 - 7:28 pm

  

  As I know it, XP is Agile, Agile is not necessarily XP. I find it a shame the solid messages behind Agile is muddled in the world of quasi-religious debate on ambigious details of a project or an example of interpretation of Agile. It seems the goals of Agile are lost on even Agilists and Cedric and perhaps I am being foolish to continue to believe the noble “Principles behind the Agile Manifesto”:
  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  Business people and developers must work together daily throughout the project.
  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  Working software is the primary measure of progress.
  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  Continuous attention to technical excellence and good design enhances agility.
  Simplicity–the art of maximizing the amount of work not done–is essential.
  The best architectures, requirements, and designs emerge from self-organizing teams.
  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  ….
  WTF is Agile now? Are we REALLY talking about Agile here?

• #74 by Arnon Rotem-Gal-Oz on June 17, 2006 - 12:21 am

  

  I think TDD is a complementary technique to other design methods and not a replacement esp. in larger projects. There are some problems that you need to analyze in higher levels of abstraction (vs. code).
  You can read more @ http://www.ddj.com/blog/architectblog/archives/2006/04/tdd_testing_or.html

• #75 by Steven E. Newton on June 17, 2006 - 10:01 am

  

  “how do you specify an exponentiation function with a test?”
  Just how would you demonstrate that the code to implement an exponentiation function is correct and works to specification?
  (Yes, I stole that question from Bob Martin’s blog.)
  Back around 1999 or so, I was as much a skeptic of agile methods (XP) as you are now. I’d be happy to elaborate on the path I took to get to where I’m an advocate now, but the summary is that I put aside my objections and tried it myself.

• #76 by Steven E. Newton on June 17, 2006 - 10:02 am

  

  “how do you specify an exponentiation function with a test?”
  Just how would you demonstrate that the code to implement an exponentiation function is correct and works to specification?
  (Yes, I stole that question from Bob Martin’s blog.)
  Back around 1999 or so, I was as much a skeptic of agile methods (XP) as you are now. I’d be happy to elaborate on the path I took to get to where I’m an advocate now, but the summary is that I put aside my objections and tried it myself.

• #77 by Steven E. Newton on June 17, 2006 - 10:20 pm

  

  Judging from the number of duplicate comments on this blog entry (my own included, probably because of a spurious error in posting that made me think my comment was NOT posted), I think the blogging software used here could be tested a bit more rigorously.

• #78 by Dave Nicolette on June 19, 2006 - 10:46 am

  

  Cedric, your article is timely. Discussions are on the increase about what “agile” methods really are, how to apply them effectively, and whether it’s even worth the effort.
  My two cents is that we (meaning the IT profession) are not well served by getting into subjective arguments about the merits of this or that based on assumptions, misinformation, opinion that has not been tempered with experience, or (worst of all) habit.
  Surely there is ample evidence that traditional methods of doing software development projects have not worked very well. The Chaos Report consistently finds under 30% of IT projects meet their objectives. The report talks about the other 70+% of projects relatively gently – it calls a project “failed” only if it is cancelled prior to completion, and refers to the rest of the general mess as “challenged.” Personally, I prefer to look at the successful projects and just call the rest of them “failed” – that means traditional methods deliver a success rate under 30%. With that in mind, it’s hard to fathom why so many people defend traditional methods as fervently as they do. Seems to me they would be interested in checking out alternatives.
  We do a lot of different kinds of work in IT. Some of it lends itself very nicely to agile methods. I’m not going to point you to an academic study that “proves” the point. I can only say that after 25 years’ experience doing the wrong things better and better each day, I was ready to call it quits and open some kind of small business, far from the IT field.
  I discovered I was not alone in questioning whether the work we do is of any value whatsoever, no matter how well we do it. Along with several others at my company, including a senior-level manager who could provide what he called “air cover” for our efforts and a customer who was thorougly disgruntled with the quality of service she had received from the IT department, we decided to look for a better way to get things done. We came across “agile” and it sounded promising, so we decided to give it a try. We gave it an honest try, engaging a consulting firm to come in and show us how to do XP from the ground up. Long story short (if you call this short), it worked very well indeed. I don’t defend agile methods because I read about them on a website and thought they sounded cool. I support agile development because I have personally experienced the difference.
  That said, I don’t claim the agile approach works for all classes of problems or all the different types of work we do in our profession. I’m a skeptic by nature, and will be the last person to sign up for a one-size-fits-all approach. But the bottom line is, frankly, the bottom line. What works, works. It isn’t a question of “belief.”
  You say agile people don’t get it, yet you (illogically, you know) tar them all with the same brush, and you (illogically again) attribute beliefs to them as a group; beliefs that would suit your own agenda, if they were true. How about we all knock off this nonsense and get back to business?
  I had a few words to say to my colleagues involved with agile methods here: http://www.davenicolette.net/agile/index.blog?entry_id=1503348. As you can see, I respect other points of view and I think we need to address the legitimate concerns of those who have doubts about the value of agile methods. To do that we have to be objective and realistic. I don’t have all the answers ready to spew, but I’m very interested in finding them.
  Is anyone else, or is this just a mud-slinging fest?

• #79 by Dave Nicolette on June 19, 2006 - 10:57 am

  

  Cedric, your article is timely. Discussions are on the increase about what “agile” methods really are, how to apply them effectively, and whether it’s even worth the effort.
  My two cents is that we (meaning the IT profession) are not well served by getting into subjective arguments about the merits of this or that based on assumptions, misinformation, opinion that has not been tempered with experience, or (worst of all) habit.
  Surely there is ample evidence that traditional methods of doing software development projects have not worked very well. The Chaos Report consistently finds under 30% of IT projects meet their objectives. The report talks about the other 70+% of projects relatively gently – it calls a project “failed” only if it is cancelled prior to completion, and refers to the rest of the general mess as “challenged.” Personally, I prefer to look at the successful projects and just call the rest of them “failed” – that means traditional methods deliver a success rate under 30%. The cancelled projects? Well, having the guts to cut your losses rather than going ahead and delivering a load of crap sounds like a form of success rather than failure, although not complete success. Wouldn’t random change – no methodology at all – yield success in the neighborhood of 50%? With that in mind, it’s hard to fathom why so many people defend traditional methods as fervently as they do. Seems to me they would be interested in checking out alternatives.
  We do a lot of different kinds of work in IT. Some of it lends itself very nicely to agile methods. I’m not going to point you to an academic study that “proves” the point. I can only say that after 25 years’ experience doing the wrong things better and better each day, I was ready to call it quits and open some kind of small business, far from the IT field.
  I discovered I was not alone in questioning whether the work we do is of any value whatsoever, no matter how well we do it. Along with several others at my company, including a senior-level manager willing to provide what he called “air cover” for our efforts and a customer who was thoroughly disgruntled with the quality of service she had received from the IT department, we decided to look for a better way to get things done. We came across “agile” and it sounded promising, so we decided to give it a try. And we gave it an honest try, too, engaging a consulting firm to come in and show us how to do XP from the ground up. We didn’t just fart around with it a bit and then claim it didn’t work.
  Long story short (if you call this short), it worked very well indeed. I don’t defend agile methods because I read about them on a website and thought they sounded cool. I support agile development because I have personally experienced the difference. I’ve received comments from satisfied customers that would be unimaginable in a traditional development project. I’ve followed up with customers two and three years after the fact to see whether the solutions we built had delivered ROI over time, and found out they have done so. It works, and it isn’t necessary to dot every “i” and cross every “t” for agile methods to deliver value, despite what some purists like to say.
  That said, I don’t claim the agile approach works for all classes of problems or all the different types of work we do in our profession. One of the reasons our agile projects have been successful is that we have always been careful to select projects that are good candidates for the approach. Most projects in our organization are still done with a waterfall process. I’m a skeptic by nature, and will be the last person to sign up for a one-size-fits-all approach. But the bottom line is, frankly, the bottom line. What works, works. It isn’t a question of “belief.”
  You say agile people don’t get it, yet you (illogically) tar them all with the same brush, and you (illogically again) attribute beliefs to them as a group; beliefs they don’t actually hold, by the way, but that sound good to a certain audience. How about we all knock off this nonsense and get back to business?
  I had a few words to say to my colleagues involved with agile methods here: http://www.davenicolette.net/agile/index.blog?entry_id=1503348. As you can see, I respect other points of view and I think we need to address the legitimate concerns of those who have doubts about the value of agile methods. To do that we have to be objective and realistic. I don’t have all the answers ready to spew, but I’m very interested in finding them.
  Is anyone else, or is this just a mud-slinging fest?

• #80 by Dave Nicolette on June 19, 2006 - 11:00 am

  

  I see what you mean about this site messing up posts. I edited mine after thinking the first attempt had not gone through. Read the second, if you’re of a mind to read either.

• #81 by Aaron Erickson on June 19, 2006 - 3:30 pm

  

  I can be pretty sure that the reason that 70% of IT projects fail is not due to the great unwashed who have not been trained in Agile yet still having access to IDEs. For those reasons, one need only review Brooks’ The Mythical Man Month, and be slightly aware of what is going on about 2 levels up in the organization, to understand why software projects sometimes fail.
  Any process at all, if honestly followed by all stakeholders involved, would probably produce better results, Agile (capitalized) included.
  What I find that works… is to do smaller projects. Expect change. Reduce the # of layers, and produce good, easy to read, code, that eliminates any abstractions that you don’t need. I can do that under TDD, but I can also do that using client/server, no TDD, and the waterfall method. And I have exactly as much evidence as the “capital A” Agilists have (as in, it works for me, therefore it works). The only important difference is, I don’t go around to other people’s blogs telling them how wrong they are if they don’t sing from the hymnal.

• #82 by Dave Nicolette on June 20, 2006 - 7:28 am

  

  I agree with Aaron that the reason 70% of IT projects fail is not due to IDEs or Agile or “the great unwashed” or any such childish, vapid nonsense. Too bad so many people seem unable or unwilling to rise above that level of discussion. Come to think of it, maybe that fact itself contributes to the problems in our profession.
  I think the historical poor performance of IT organizations has to do with the gradual accretion of a thick callus of bureacracy around IT work over a period of decades. There was a time when it was routine for the producers and consumers of IT services to talk directly to each other rather than depending on a pile of formal documents and a bureaucratic layer of intermediaries, called Business Analysts or a similar title, who understand neither the business nor the technology and yet are required (by management edict) to handle all communication between producers and consumers. Under those circumstances, it hardly matters what sort of methodology one uses or how talented and capable the project team may be; they are going to have a hard time delivering real value no matter what they do or how they do it.
  The old saw that any process will work as long as good people do their best is all well and good, but unfortunately that’s not the status quo in the IT industry. There are institutionalized barriers to success that can’t be overcome by talent or good intentions alone. It’s time for us to revisit the methods we use in our work and assess them in light of our customers’ needs. If you don’t like the word “agile” then use another word. But don’t dismiss the need for change out of hand just because of a word.
  Aaron alludes to the primary barrier to success when he writes, “…if honestly followed by all stakeholders involved.” IT organizations today are characterized by obfuscation, blame-shifting, and avoidance of accountability. People who don’t contribute to the business in any concrete way use process and ritual to justify their continued employment. They concoct myths that become rooted in organizational culture through repetition, such as the myth that it is impossible for a business person and a technical person to understand one another, or that it is impossible to begin writing any code before every detail of a design is codified in a document. The goal of heavyweight IT processes, like government agencies, is to ensure their own continued existence, not to help deliver genuine value. Perhaps that is due in part to the fact that IT organizations, like government agencies, are overhead; they are cost centers, not profit centers. Whatever the cause, the dishonesty inherent in any dense bureaucracy, including the bureaucracy of traditional IT organizations, accounts for the strong emphasis in both the lean and agile movements on the concept of transparency, which boils down to simple honesty. “If honestly followed,” yes indeed. If. Big if.
  According to recent survey results, businesses are exploring alternative approaches to IT projects because they are looking for four specific benefits: (a) reducing time to market, (b) improving quality, (c) aligning results with business needs, and (d) reducing cost. Whether you think agile or lean or SOA or some hybrid approach represents a useful way to achieve those goals, as long as you can quantify the value in some objective way then it’s all good. Silly “religious” arguments don’t address the four business drivers that are at the top of our customers’ wish lists these days. I don’t think we’re going to get very far unless we can deliver one or more of those four benefits, one way or another.
  Ironically, Aaron offers some very agile suggestions even while disparaging the whole idea of agile development: “…do smaller projects. Expect change. Reduce the # of layers, and produce good, easy to read, code, that eliminates any abstractions that you don’t need.” Makes you wonder who he’s arguing with. A strawman, perhaps.
  After he knocks down the strawman – a task that shouldn’t take too long – maybe he’ll join the rest of us in trying to improve our profession. I hope so. With a historical success rate under 30%, we need all the help we can get.

• #83 by Aaron Erickson on June 22, 2006 - 8:39 am

  

  Let me respond simply… I loved agile before it became Agile.
  🙂

• #84 by Anonymous on July 2, 2006 - 2:07 am

  

  Oh, ummm, sorry. I was too busy coding; what were you jibbering on about?

• #85 by 抛光 on July 5, 2006 - 11:18 pm

  

  抛光
  磨料

• #86 by Greg Ferguson on August 11, 2006 - 6:07 am

  

  There’s something very important to note here with regards to the anecdotes supplied. Several of the people listing their success with Agile development missed something really important.
  “Leaders” are charismatic and able to find ways to make things work. Proponents of Agile are made up of individuals from that leader pool.
  In other words, the proponents are not team members – they are team leaders, a role which Agile has discounted with complete hypocrisy.
  Agile may be contributing to success of these entrepeneurial people – but when evaluting anecdotes one cannot separate the tool from the team leader.
  Saying that “teams failed to apply it” is flat-out a copout. It is the same as admitting THE TOOL FAILED TO BE APPLIED. Why harp on this distinction – rephrasing questions is part of logical discovery, a very important part.
  After we ask the question differently, answers begin to suggest themselves. One being it is very possibly because the team is different, even if it is just that one magic person to make it all work was taken away: the individual mattered more than the tool to the group dynamic.
  Looking to that team afterwards for success of the next iteration isn’t sufficient either. Impact of an individual lasts a long time. A real teacher can pass on coping strategies that outlast the teacher’s presence.
  Use of Agile is getting rid of the manager interference and bureaucracy who otherwise constrain individual talent of such leaders to organize teams, to seek out brilliant but hesistant members and encourage their contribution.
  Okay – how about “real world” since this seems to be where all such discussions here go.
  Quick example, I’ve met one of the people here who’ve pointed to anecdotal success – Mishkin. He’s smart, a quick thinker and highly personable. He is a leader. He is an entrepeneur. He will be successful no matter what he used.
  His involvement may have been the magic, not the tool he used. It doesn’t make Agile the winner – it means he is a winner.
  The individual has dynamic effects upon any team. The right person is worth more than a doctrine.
  Focussing on what adds value isn’t “owned by Agile”. Involving the customer, quick iterations – yes Agile has promoted these but they are what brings value. Collocating a team has been demonstrated repeatedly to enhance stress levels as noted by elevations of 40% above baseline epinephrine levels in urine samples of members.
  Group dynamics under such conditions also show fewer attempts to make ergonomic adjustments and fewere attempts to offer alternatives. In other words, this kills off innovation.
  A good leader can continue to infuse life into that environment. It does not make the environment optimal.
  I heard somewhere that the IQ of a group can be found by taking its smartest person and dividing by the number of people in that group. While humorous and an obvious joke, it is also food for thought.

• #87 by Greg Ferguson on August 11, 2006 - 6:11 am

  

  Something I should also have mentioned…with regards to statistics.
  70% of waterfall projects fail.
  Two-thirds of companies trying to create Agile teams fail.
  Basic math – 2/3 = 67%. 67% and 70% sound an awful lot alike to me…

• #88 by Anonymous on August 16, 2006 - 6:59 pm

  

  Greg, your comments present interesting food for thought.
  When you talk about charismatic leaders – well, agile development is really supposed to be about the team and not about any given individual. In my experience, that’s been the case. But it’s also been my experience that in order to introduce any sort of alternative to the status quo in a traditional IT shop really does require charismatic leadership. That sort of leadership is necessary to drive change; that would be true regardless of exactly what we wanted to change. It isn’t unique to agile development.
  And I must say those teams that functioned well with the agile style of work were not composed of “average” developers. It’s a demanding and intense way to work. Any weaknesses in one’s knowledge or skills is immediately exposed. People who can take that as a learning opportunity do well with agile work, and others might not. I can see how stress levels might be elevated – when people are asked to work that way when it’s not their nature. For those of us who thrive on the approach, the same characteristics of collocation that cause stress in others don’t have the same effect. Instead, it’s invigorating and energizing. I’ll leave the urine samples to you (not my thing), but maybe one conclusion we can draw is that agile work just isn’t for everyone.
  At our company we came up with some recruitment guidelines based on personality traits we thought would be compatible with agile work. Later, I informally correlated those traits with the (admittedly old-hat) Myers-Briggs personality type categories. Matching up the compatible types, I found (from a book on the personality type system) that about 14% of humans fit into those particular groups. Obviously that’s not very scientific, but it does suggest that agile development isn’t something we can just substitute, whole-hog, for traditional methods. The majority of people just won’t go for it.
  I don’t understand what you mean by “ergonomic adjustments.” It sounds like it might have something to do with adjustable seating, but I have a feeling that isn’t what you meant.
  You’re quite right that focusing on value isn’t “owned” by agile. I and others at my company came across agile when we were looking for ways to improve the value we brought to the enterprise. We didn’t start out with any predisposition to use agile. We had never heard of it. We were looking for a good way to bring value, and that’s what we found. It worked in our environment, but not without considerable effort on our part and not without qualified help from an agile consultancy to get us up to speed. It is far from easy to do right, and maybe that’s one of the problems with successful adoption. When it’s done right, it works really well. Whatever problems people are experiencing, I think we do ourselves a disservice if we simply dismiss it all as “agile doesn’t work.”
  Regarding the statistics people like to throw around…it occurs to me that a 70% failure rate using methods that have been very well established over the past 4 or 5 decades is a different matter than a 67% learning-curve-difficulty-rate on the part of organizations that are just trying out something new for the first time. They don’t sound an awful lot alike to me. Sure, the numbers are close together, but they don’t represent the same sort of problem.

• #89 by Anonymous on August 16, 2006 - 7:00 pm

  

  Greg, your comments present interesting food for thought.
  When you talk about charismatic leaders – well, agile development is really supposed to be about the team and not about any given individual. In my experience, that’s been the case. But it’s also been my experience that in order to introduce any sort of alternative to the status quo in a traditional IT shop really does require charismatic leadership. That sort of leadership is necessary to drive change; that would be true regardless of exactly what we wanted to change. It isn’t unique to agile development.
  And I must say those teams that functioned well with the agile style of work were not composed of “average” developers. It’s a demanding and intense way to work. Any weaknesses in one’s knowledge or skills is immediately exposed. People who can take that as a learning opportunity do well with agile work, and others might not. I can see how stress levels might be elevated – when people are asked to work that way when it’s not their nature. For those of us who thrive on the approach, the same characteristics of collocation that cause stress in others don’t have the same effect. Instead, it’s invigorating and energizing. I’ll leave the urine samples to you (not my thing), but maybe one conclusion we can draw is that agile work just isn’t for everyone.
  At our company we came up with some recruitment guidelines based on personality traits we thought would be compatible with agile work. Later, I informally correlated those traits with the (admittedly old-hat) Myers-Briggs personality type categories. Matching up the compatible types, I found (from a book on the personality type system) that about 14% of humans fit into those particular groups. Obviously that’s not very scientific, but it does suggest that agile development isn’t something we can just substitute, whole-hog, for traditional methods. The majority of people just won’t go for it.
  I don’t understand what you mean by “ergonomic adjustments.” It sounds like it might have something to do with adjustable seating, but I have a feeling that isn’t what you meant.
  You’re quite right that focusing on value isn’t “owned” by agile. I and others at my company came across agile when we were looking for ways to improve the value we brought to the enterprise. We didn’t start out with any predisposition to use agile. We had never heard of it. We were looking for a good way to bring value, and that’s what we found. It worked in our environment, but not without considerable effort on our part and not without qualified help from an agile consultancy to get us up to speed. It is far from easy to do right, and maybe that’s one of the problems with successful adoption. When it’s done right, it works really well. Whatever problems people are experiencing, I think we do ourselves a disservice if we simply dismiss it all as “agile doesn’t work.”
  Regarding the statistics people like to throw around…it occurs to me that a 70% failure rate using methods that have been very well established over the past 4 or 5 decades is a different matter than a 67% learning-curve-difficulty-rate on the part of organizations that are just trying out something new for the first time. They don’t sound an awful lot alike to me. Sure, the numbers are close together, but they don’t represent the same sort of problem.

• #90 by Greg Ferguson on August 24, 2006 - 8:59 am

  

  Some valid points there. Though I think they open other cans of worms.
  How many of the “failed” waterfall projects brought in people from good waterfall agencies to help them succeed? The same can apply there – waterfall “doesn’t work” is too broad a statement.
  Second, sure some of those Agile failures are due to difficult learning curves. However, I NEVER see anyone seriously fault the process. That reeks of subjective discarding of possible problems.
  The urine analysis is used as a reference to a REAL number. Not anecdotal. While I appreciate your humour, it also seems something of a dodge.
  Stress is chronically elevated as measured relative to waterfall. It’s just not reported and/or recognized. This is confirmed with hard data.
  Ergonomic adjustments – yes, I referred to adjustable seating, keyboard placements, etc. All the things known to be required but ignored which are a subtle workplace hazard.
  They are also another measure of stress response. Lack of ergonomic adjustment = greater incidence of injury. It also closely correlates with chronic stress.
  It is interesting to note that the stress elevations all seem to correlate to radical collocation.

• #91 by axvia on August 31, 2006 - 5:01 am

  

  we are doing Agile in India. More info on process and methology is on http://www.xebia.in

• #92 by Clarety Consulting on September 14, 2006 - 11:22 am

  

  Agile is lacking the agility to evolve and take on board criticism.
  Standard defence of failed projects (of which there are an increasing number) include the following:
  1. Wrong or poor implementation.
  2. Lack of understanding concerning the manifesto.
  3. Half hearted application.
  The list is endless.
  However, you’ll never find the Agilista’s blaming Agile itself! Vested interests maybe?
  Anything or anybody unwilling to learn from bona fide criticism is anything but Agile in nature!
  Check out http://www.claretyconsulting.com,
  there’s a whole ongoing debate on this at the moment.
  Cheers

• #93 by Rick on September 19, 2006 - 9:58 pm

  

  My .02: http://rickgaribay.net/posts/292.aspx

• #94 by Richard Freytag on October 7, 2006 - 5:32 pm

  

  To the question you support “how do you specify an exponentiation function with a test?” the answer is – with logic programming.
  The following is taken from a Prolog tutorial (http://cs.wwc.edu/~cs_dept/KU/PR/Prolog.html)
  and gives the following test (rule) defintion of exponentiation:
  “Logic programming definition of Exponentiation
  % exp(N,X,Z) <- Z is X**N
  exp(s(M),0,0) :- natural_number(M).
  exp(0,s(M),s(0)) :- natural_number(M).
  exp(s(N),X,Z) :- exp(N,X,Y), times(X,Y,Z).
  ”
  So tests can be executable specs.
  I would also agree that if you can’t test it its (maybe not useless but), probably random or irreproducable or unreliable.

• #95 by Computer Scientist on December 4, 2006 - 6:25 am

  

  Any serious engineer will learn the applicability of their tools to the problem at hand. It is a fundamental concept of being an engineer. Misapplication of a wonderful tool is just as bad as using poor/outdated tools.

• #96 by vinothkumar on December 5, 2006 - 4:01 am

  

  My view is, Agile doesnt work all times. It works if you have a perfect team . But not all teams can be perfect.
  This is the situation atleast here in india.
  software service companies trying get a contract ….
  One company says I need 10 resources ( 5 pairs ) . that will cost you 10 * 100$ per day .
  The second company says i need 5 resources . that will cost the 5*100$ per day.
  Now to which company the contract goes . Unless the IT manager of the company giving the contract knows the advantages of Pair programming which has a probability of 5%. the second company wins the contract. The employees of first company gets fired.
  saving the job is more important that following principles.
  In india , the trend is Deliver first then fix later. Delivery date will never be changed even if resources reduced, Bugs increased …. and also you will get to see the customer only when he comes for his vacation to india.
  TDD stops at the point when there is not even time to type the code for the features.
  How can i find time to write test , if i dont find time to not even TYPE(literally) the code .
  Agile people dont get it. Anything that is Agile in the world can get out of control easily. Its basic engineering. You change too fast and you burn out . you try to be agile for prolonged time , you will get burnt out.
  Regarding the Documentation , in India , people jump jobs every 6 months . Without documentation , its impossible for knowledge sharing . Even the worst Documentations can still help a newbie.
  Im not saying agile is bad. Its great but definitely not practical.
  Agile Programmers are like scientists . They never understand the cultural , political,economical problems . All they know is Principles and practices.
  All Agile People (elite Military generals) , enough speaking about principles and saying “u should have done agile in the first place” , get down to the war field and show us the way .
  thanks
  vinothkumar
  “I ask for a solution , Agile gives me a principle”

• #97 by M.SANKAR on January 5, 2007 - 8:29 am

  

  I WANT TO JOIN YOUR TEAM WORKER I AM SCIENCE INTRESTED PERSON

• #98 by M.SANKAR on January 5, 2007 - 8:30 am

  

  I WANT TO JOIN YOUR TEAM WORKER I AM SCIENCE INTRESTED PERSON

• #99 by kevin brady on March 29, 2008 - 7:10 am

  

  Love the article. I agree with ALL your comments. The long lists of comments looks like gorilla commenting by those members of the Agile Cult all earning fees no doubt on the back of the Agile revolution which is built on the backs of naive developers who are promised golden eggs and release from project managers telling them to deliver to cost time and quality standards. If only Agile could deliver the promises it offers without the potential of financial ruin for those investors in such uncontrolled self assembly projects. Well if only 🙂

• #100 by Valeri S. on June 12, 2008 - 6:17 pm

  

  I agree with all Cedric’s points. No need to push the whole new methodology. The timely project delivery, high quality code, well designed code, testable & documented code, proper unit tests that cover business logic, efficient customer/business interactions, – all this is normally done if you have a good team. The elitist agile rock stars, who trash other developers who-don’t-get-it, ruin productive team spirit. Project can break in cover-your-ass pieces. These superstars will create only core components (i.e. establishing best practices), leaving the hardest and nastiest parts to other folks, who then have to fix superstar’s code. Try to document the system by creating unit tests for host transactions, database stored procedures, file system dependent configuration code, web services that post messages to 3rd party MQ; and the project is guaranteed to fail. There is no substitute for a good, well though-out and documented architecture AND design, and normal project planning. And there is no substitute for even contribution. Every one in the team must do his own piece of work. Either you do your work, or you don’t, and use agile methodology in very *agile way* to push your work on shoulders of others.

• #101 by Scott on December 19, 2008 - 1:04 pm

  

  ‘Whereof one cannot speak, thereof one must be silent’.
  So – from experience on software projects with hundreds of thousand of lines of code accross multiple technologies and business units in a fortune 100…
  All activities in the SDLC have a cost/benefit. One should assess the cost/benefit of each activity and try to optimize it.
  Though we are not religious about it, we keep trying to improve what we do a little bit at a time. Agile principles, applied judiciously help us to improve the cost/benefit ratio.
  I suggest that there is enough evidence that one should try it in a low-risk environment with willing participants. If it works, keep it. If it doesn’t then figure out what you could have done differently and fix it next time.
  Of course that last sentence should be applied regardless of methodology.
  Large organizations with history tend to have lots of politics. If the message sounds radical or will clearly result in organizational change, it’s going to be hard to gain support.
  I’m extremely surprised to see such passionate discourse against Agile come from within a company such as Google. I’d always thought them to be among the more open-minded corporate cultures.

• #102 by Eric S on August 5, 2010 - 11:02 am

  

  The problem is that Agile has become a dogma. Dogma shuts down thinking and discussion. You can no longer discuss the trade offs of benefit vs cost with regard to applying any given Agile practive in a given situation with Agilists because they will not admit such trade offs can ever weigh against an item of dogma. Agile principles have value, applied intelligently and considered in relation to each situation. Having this word “Agile” to encompass these principles has outlived it’s value.
  I’d be happy to see it die, but it will not any time soon, because it has become entrenched in many organizations and many people make their livelihood from it. It will continue to poison software development culture until it is eclipsed by the next buzzword dogma.

• #103 by Andrew Darnell on August 16, 2010 - 7:06 am

  

  Arghhh…
  I have seen many people take a perfectly good code base and then start ‘sprinting for the line’. The line moves, and they continue sprinting, and they sprint some more… It is getting harder because the ground is changing under peoples feet and Bill over there re-factored a class which broke one of Betty’s assumptions which broke the build for a couple of days before it was tracked down, and in the meantime fifty other change lists went in and now even though the original problem is fixed the build is consistently broken. Never mind some one else will fix it gotta get the new functionality for the sales demo done by tomorrow…
  When you look closely, people are spending lots of time debugging rather than coding. The other behaviour I have seen is people avoiding particular areas of code because they seem to be fragile.
  The culture shift has been accomplished…
  We have all seen projects like this, where a shining tower of simplicity and purity of vision has been changed into a world of intellectual poverty and make do, worthy of the favelas of Rio de Janeiro.
  The usual outcome is to then completely re-engineer the next version with a new team because the previous team left the company demoralised, hopefully for happier projects.
  It always surprises me how little discipline needs to slip before chaos reigns, and how much chaos bright people can actually manage and put up with before succumbing to the inevitable…
  Good agile practice is high discipline, not low discipline…
  Dogma is bad, but we have to learn from experience…

• #104 by Rich on August 21, 2010 - 12:00 pm

  

  “Dogma is bad” mmmmm irony

• #105 by Giel van Schijndel on August 21, 2010 - 1:51 pm

  

  First regarding how you dispute the second claim, “If it’s not testable, it’s useless”. While I agree that this guarantees you’re audience to think of you as a crackpot, you dispute it by stating that untested software isn’t (necessarily) bad. The statement was about it being test*able* though, i.e. if it cannot be tested it’s useless. For that I can give a very simple example however: development and maintenance of drivers and embedded software, i.e. often enough you write code for hardware you don’t even have access to so the only test you can perform is “does it compile?” and deal with the bug reports when they come in.
  As for you associating Agilists’ badness with open source projects. I’m most definitely not an Agilist (much more an anarchist/non-conventionalist, i.e. I question *every* method I’m expected to use), but about 60~70% of my software development is on open source projects (used to be 100%), and those projects I work on (usually) are of much higher quality than the closed source bases I work with.
  Heck, the largest closed source base I work with was developed with some of the aspects of Agile development I despise most; the code *is* the spec and documentation and testing being more important than performing a code review of (critical parts of) the code every now and then. Basically all projects I worked on where “Agile development” was claimed to be used the reality was: no consistent method whatsoever was used, i.e. the used practices were *completely* ad-hoc. That’s my most significant problem with Agile development really: it deteriorates way too easily into ad-hoc development.

• #106 by Christopher Dunn on August 21, 2010 - 3:20 pm

  

  Testing exp() is easy: Test at random points against a known correct implementation, in addition to a few obvious points and any points that have failed in the past. In other words, most of the test changes every time you run it. That can provide whatever level of certainty you desire.
  Minor quibbles aside, I do agree with the author here, basically. A test is *not* a spec. However, there is no spec if there are no acceptance tests. It’s too easy for customers to keep their requests unspecific, even with reams of English prose and myriad diagrams.
  I do not believe that TDD advocates really are dogmatic. They want the center of opinion to move toward writing tests first. Where I’ve worked, the level of testing has not sufficed, and excuses are rampant. Writing tests in advance is a practical way to ensure that tests are actually written, kind of like obtaining a warrant before breaking into somebody’s house.

• #107 by Eduardo on August 21, 2010 - 3:23 pm

  

  I’ve worked on 50+ people agile teams (20+ developers) as well as 50+ people waterfall teams, and you’re simply wrong.
  I specially like your comment about “Having a 10 line paragraph would have helped a lot when I started looking at the code”. I heard that a million times from people joining the team. And you know what? After they worked on the project for a few weeks/months, if you asked them, they would say that having those comments would have been a mistake and a waste.
  Your problem seems to be that you just experienced “but-am” agile projects. “We’re doing Agile, but..am.. we don’t really to TDD. We’re doing Agile but..am.. we don’t do pair programming”. Or the worse one “We’re doing agile, but we just do scrum, no xp practices”.
  There’s a reason why the XP has a lot of practices. All of them bring something to the table to make the other practices work better. So, for example, when people say “its best not to have comments in the code”, that means that, when you join an Agile team, you’ll be pair programming with an experienced developer, and the explanation you want to read will really be told to you by that person. That contact with the developer will be a lot more valuable than 10 lines of text that will (yes, they will, I’ve seen this a million times) be old and wrong.
  There are good and bad presenters for pretty much any topic in the world. I would suggest you look for some better ones instead of taking conclusions based on a couple of people you didn’t like, and then complain if you still want to. A great conference to see people like that will happen in Chicago: http://scna.softwarecraftsmanship.org/ . Google for “Uncle Bob presentation” and watch a couple of videos.
  Good luck learning more, or good luck going to the “good” old waterfall.

• #108 by Cale Gibbard on August 21, 2010 - 4:27 pm

  

  I’m not particularly an advocate of TDD, but here’s how I might specify one sort of exponentiation function (written infix as ^) using the QuickCheck testing library in Haskell:
  quickCheck $ \x -> x^0 == 1
  quickCheck $ \x -> x^1 == x
  quickCheck $ \x (NonNegative a) (NonNegative b) -> x^(a + b) == x^a * x^b
  Here I’m assuming that our exponentiation function wants the exponents to be nonnegative integers. Depending on which definition of exponentiation we were really trying to capture, variations or extensions of those properties might be in order, but I think that’s a decent start. It completely characterises exponentiation for non-negative integer exponents.
  Exponentiation is an easy example because there are lots of well-known algebraic laws you could test. Of course, running the tests in this case will never conclusively prove that your implementation is correct, only catch a decent portion of incorrect implementations a decent portion of the time. Still, writing some tests is often a good excuse for thinking about the algebraic properties that your code ought to satisfy, even if you’re too lazy to write down any proofs.
  Libraries with well-thought-out algebraic properties in my experience tend to be the ones which are nicest to actually use, and which scale nicely down to small problems and up to large ones, or from the problems they were originally designed for to new applications.
  While I don’t tend to write tests first (and often *gasp* don’t write tests at all), I do spend a lot of time thinking about the relationships and properties that my code needs to satisfy. (Usually much more time than it ends up taking to write the code.)

• #109 by Paddy3118 on August 21, 2010 - 7:25 pm

  

  You write: “Software is shipped with untested parts every day, and just because it’s not entirely tested doesn’t mean it’s bad software ”
  I hope you just got carried away and didn’t mean that. Or if you did mean that, then just because you can get away with shipping untested code doesn’t make it good code. Don’t you even aspire to some form of engineering discipline?

• #110 by Daniel Ribeiro on August 21, 2010 - 7:28 pm

  

  I like this kind of controversy. It is good to make people reaffirm their convictions, so that we do not keep repeating things like mantras, instead of actually thinking and considering practices for ourselves (Kent Beck shared a bit of his reframings on Startup’s Lesson Learned, which i commented on this other post: http://www.abetterstartup.com/2010/05/bootstrapping-versus-best-practice-in-lean-startups/). Sometimes I feel we don’t have near enough controversy.
  On the other hand, it is interesting that this old thread not only caught up Reddit’s attention (as you mentioned on twitter), but also Michael Feather’s himself (http://michaelfeathers.typepad.com/michael_feathers_blog/2010/08/testng-and-what-wed-like-code-to-be.html, twitted by Kent Beck). He even responds with movies of both TestNG and Junit’s source code visualization.
  Just hope you are not overwhelmed by the controversy, and keep the interesting posts coming.

• #111 by SudarshanP on August 21, 2010 - 8:52 pm

  

  How do you write a test for the implementation of e^x when there is no existing algo for the same. d(e^x)/dx = e^x. So take random x values and check whether exp(x+dx)-exp(x)/dx = exp(x).
  To handle the finite precision of digital arithmatic, we can subtract LHS from RHS to see how big the difference is. The smaller the difference, the better the implementation. Before “your coder” gets to lay his hands on the code, a “mathematician” can “specify” what is acceptable and unaceptable from your function.
  Where it is “possible” to be clear, it is better to “be clear” than “appear professional”. I wonder if a 10 page document that makes some vague description about the exponential function would be a tenth as useful as a clearly written test. That said, achieving clarity through a test is “pragmatism”. Thinking there is a silver bullet to all problems is stupidilty.

• #112 by bestmore on August 21, 2010 - 9:24 pm

  

  Are learning. It was accepted.

• #113 by Joe on August 21, 2010 - 10:01 pm

  

  If you look at unit tests like they are executable specs, yes, they may have bugs. You seem to state this as an argument for non-executable specs, word docs, activity diagrams, whatever. Wouldn’t you agree that non-executable specs are also prone to bugs, incompleteness and possibly even worse, staleness?
  Personally, I try to write perfect code, but I don’t. You don’t. Nobody does. Leaving a trail of units tests at least lets me communicate to my fellow developers that, hey, my code isn’t perfect, but here’s my current understanding of how it should work. If you do something that breaks it, then we’re certainly not on the same page. Maybe you’re wrong, maybe I’m wrong, but there’s a conflict that needs to be resolved quickly before we start building on top of a potentially broken design.

• #114 by Erik E on August 22, 2010 - 1:05 am

  

  I diagree with the idea that so someone heretter propose that you don’t need comments. A lot of people who wrote the 3 mill loc app you are working on might have left the company long time ago. What are you supposed to do then? Reverse engineer the app every time you work on a new piece? Interfaces should be documented. At least describe what the purpose is if
  I
  I

• #115 by Erik E on August 22, 2010 - 1:08 am

  

  I diagree with the idea that so someone heretter propose that you don’t need comments. A lot of people who wrote the 3 mill loc app you are working on might have left the company long time ago. The purpose of classes should be documented. If that changes to frequently you must be doing something wrong. I like the philosophy of agle but agree it gets a bit dogmatic at times

• #116 by Medwezys on August 22, 2010 - 1:32 am

  

  Offtopic: the article is hardly readable on iPhone because of font-bg colors, you should consider changing some css if you want it to be usable for mobile users 🙂

• #117 by Icelander on August 22, 2010 - 6:39 am

  

  We’re all doing TDD every time we write code. Someone has expectations of what the program should be doing and we write code until it meets those expectations. In most places I’ve worked it’s been management having some vague idea of how it should work and programmers constantly asking them if they can stop working yet.
  All unit testing does is provide a way for programmers to define the expectations before they start writing code, based on specs from management. It shortens the feedback loop so development can happen more quickly.
  Now, if management changes their expectations or doesn’t allow enough time for writing test cases then of course TDD is going to look like a waste of time. But you’re going to have to check your code against something eventually, otherwise you’re writing random strings.
  I don’t view tests as replacement for documentation, but as a way to make sure future modifications don’t break existing functionality. Recently I’ve been working on a very fragile code base with no tests. Most of my time was spent searching the code to find where to put my modifications so that I didn’t break the code. If there were
  And the biggest improvement in my productivity has been my insistence on getting stakeholders to WRITE DOWN (along with a date) what they want done and how long I think it’s going to take. Most of the managers I’ve worked with have resisted this, and every project I haven’t done it for has either had huge scope creep or turned into a death march.

• #118 by Mike on August 22, 2010 - 5:00 pm

  

  A small nit:
  “how do you specify an exponentiation function with a test?”
  Easy: verify b^y = x log_{b} x = y

• #119 by Mike on August 22, 2010 - 5:03 pm

  

  Ugh, blog software stripped a rather important symbol out of that…
  restated:
  verify: b^y = x iff log_{b} x = y

• #120 by J on August 22, 2010 - 7:38 pm

  

  “Very often, Agilists simply forget that their job is to produce software that satisfies customers, not software that meets some golden software engineering scale.”
  I am currently studying Agile Programming at university, and either Agile Programming has evolved in the last four years or you have missed a key element in Agile and Extreme Practices. When beginning the first iteration the FIRST pieces of implementation added are the ones that gives the customer the MOST value.

• #121 by Pleb on August 22, 2010 - 7:43 pm

  

  IMO, TDD is great for the first 5 minutes. Then it’s annoying. My version is TDWCWT. Think Design, Write Code, Write Tests. So, no the test don’t come last, but having thought about the design confirm while writing code that it works by writing the test.
  To me the main advantage of unit testing is better code quality and the ability to rerun tests! Firing up the software to test a change is required, but counter productive if that’s the only method of testing.

• #122 by Maxim Zaks on August 22, 2010 - 8:07 pm

  

  Very interesting post and very interesting comments. 
  There are many good pro arguments for TDD and agile in the comments. But in my opinion the most important pro argument is Feedback. 
  XP is based on the idea of feedback loops. You get it from pair programming, testing, continuos integration a.s.o.
  If you don’t test your code you will get feedback from your peer (if you making code reviews), QA (if you have one), or in the worst case from customer. 
  A test can be seen as customer that has some expectations for your product. And in the real world project there is always a customer first. 
  So that means: 
  test first = customer first
  If you think about documentation. What is the easiest way to understand a product? Look how it is used. “Monkey see, monkey do” principal.
  And as a test is a user, it describes you the usage.

• #123 by Vital on August 22, 2010 - 8:29 pm

  

  I have heard all sorts of excuses from people not wanting to write unit tests. And they did not write them at the end. With no exceptions, in 100% cases, the project ended up in if not being a total disaster, but very close to that. No matter how great the design was and how good the people were. This is the project itself, and I am not even mentioning the further supportability issues and technical depth created by famous “implement this feature quickly” approach. Also, in 100% cases my team, which is doing TDD, is way quicker in not just implementing those features, but actually getting them to work without breaking half of the other functionality.
  Unit testing is used anywhere else in the industry. Only an idiot will install a hydraulic cylinder on the Airbus 380 without testing it first. Well, it can actually happen, but this idiot will be jobless in no time. Why the hell do software developers think they are special?
  Software is one of the most complex engineering areas. As process, software development is prone to errors, and the biggest problem here is that the more time is passed since the mistake was made the harder it gets to locate it and fix. Unit tests eliminate about 95% of such errors; they also eliminate the need in debugging the application. I had several systems designed, implemented and commissioned without ever starting the debugger. It saved us an enormous amount of time.
  Of course, on a downside, most people around us first found it hard to believe that software can just work at the first try. But they got used to it.
  And, at the end of the day, if it’s worth writing, it’s worth testing. If it not worth testing, why bother then?
  Also, Agile != TDD.

• #124 by erazer on August 22, 2010 - 9:15 pm

  

  This rings a familiar bell. Though I don’t agree with this blog entry entirely, there are similar situations that I come across frequently. I have seen developers not writing even a single line of a comment for an entire codebase (~20K). “Tests are the specs, the documentation” – that is a comment I often hear. I don’t agree that you have to spend minutes or hours understanding code where a few lines of comment that can be comprehended in a couple of minutes would suffice.
  Vincent Massol’s work on Cargo (http://cargo.codehaus.org/) is one of the better disciplined works I have seen over years in open source space.

• #125 by Davy Robertson on August 22, 2010 - 10:27 pm

  

  Yes I think you are quite wrong here. You absolutley can test the whole solution. And why cant a test be a spec ? Most specs are usually wrong – if its in the form of a test – then its got clear defined inputs and outputs. You wouldnt get away without properly testing manufactured goods – difference is you test it during design and development. I think the problem is that software engineers like yourself are the ones who dont live in the real world. Still hanging on to the idea the software is like a movie – a creative product – thats perfect even with its imperfections – hogwash old boy – software quality is as important as the design. Both need to work together.

• #126 by Petra Eckhart on August 22, 2010 - 10:47 pm

  

  I totally agree with #23, saying: Agile !=TDD
  Agile is a buzz word and while almost every company now claims to work agile, they all do it in a different way, which makes ‘agile’ a very fuzzy word, making it hard to claim if it is a good or bad way to program.
  Do you want an agile development for your project? Ask if they can explain how they work, without using the word agile…. That gives you a hint weather it is good for your project or not. It depends on what they do and what kind of project you have.
  TDD has lots of value… but please don‘t use it as a law which solves everything. PE, you shouldn’t forget the influence of the user (do usability tests) . If you got a client who is not that clear in describing what they want, I think making a rough untested version is a good thing: you can use it to find out if you are on the same track as the client. If you use a code-generation tool, writing tests for the CRUD actions is not a very useful action and if you write your own code, please do! Be pragmatic!

• #127 by flukywotsit on August 22, 2010 - 11:25 pm

  

  I have worked in both the old style development and with the more agile approach with scrum though i am yet to experience paired programming.
  And i would never through away my technical requirements document as some agile approaches preach as its to useful for when office politics comes into play, I do develop with a sort of TDD approach, using scrum.
  There will be developers out there that will want to hold on to the oldways and they do work, but i would say that agile though no were near perfect, it does kill off the need for a project manager and as some one who has worked in the public sector that is the best thing in the world.
  Personally I think agile comes down to the quality of your team, i would not want to use it with a team of just out of uni developers, but adding one or two to a team of seasoned professionals. But a bunch of newbies working giving me a full design to look at, and unit testing there code as they go along with a little quality checks by a seasoned programmer could probably develop something good.
  In the end bosses will aways want something yesterday, and be looking for what can be cut from the development time, so either way there will be times you will not be following any best practices process.

• #128 by R00bN00b on August 22, 2010 - 11:49 pm

  

  Amen to this article, for the most part. I do disagree about comments though, they’re usually crap and trying to figure out how the code following solves the outdated comment can make a 10 second glance at the code logic take 10 minutes. Perhaps some of us are more fluent in code than others? I can sure say I’d rather a chunk of java, C#, or php over a textual narrative any day. If you put VB in there then maybe I’d prefer the typo filled nonsensical narrative written in broken English that doesn’t appear to actually communicate anything at all.
  I know the answer to the end-all-and-be-all of programming practices! Hire smart people, that are only territorially defensive when logic demands it. Get them awesome equipment and whatever tools they ask for, even if it’s old unsupported IDE software. Then get the frack out their way (and keep blonde bimbos with invented titles and physical education degrees out of their way too) and let them work wonders. You don’t even need a spec, smart people do cool stuff no matter what pile of turds of an idea they’re handed. A team of smart people do even cooler stuff. Add in one numbskull and that single vacuum of intellect will render all powers null and void. In other words fire more people you dodos. Hire smart people, fire dumb people. Easy peasy.

• #129 by Richard Stanton on August 23, 2010 - 12:02 am

  

  Agile (now known as “fragile” in our workplace) worked absolutely fine with project involving 2 programmers, 1 customer, a 7 page website. Even updating it 7 months later was no problem.
  However, the methods failed miserably with 3 UI designers, 1 Systems analyst, 1 database architect, 1 spec author, 4 coders and 2.5 million lines of code. (actually, it failed way before we hit that point).
  Horses for courses.
  Great for low-risk startups and “programmed in a back-bedroom” smaller projects. And a much nicer way to code because things are developed more ‘on the fly’ (and as a coder I hate having to document things because I’m fundamentally lazy at heart!)
  I believe Agile still beats pure waterfall methodologies even on larger projects; just inject some common sense and keep the “Objectives”, ERD diagrams and tester-checklist documentation in step with the code! (even better, get a spec-author to do the documentation for you 😉

• #130 by Nathan Manning - Nashville, TN on August 23, 2010 - 12:27 am

  

  A while back I spent some time working at the NASA Data Center with a team that developed ESB integrations for the Constellation program within the Space Exploration Directorate. We had a quality problem, and decided to address it within the development team. I was charged with development white-box testing and regression testing. I ultimately turned that into a Continuous Integration Test & Build (CIBT) process. The team was supposedly already using TDD. I found that what unit test code that existed generally only tested what the developer thought would be valid input. There were no negative tests and no exception tests. Developers always do this – Assume their code will be receive only expected input.
  The documentation and specs were even further out of date and that is just as bad. You cannot write a test plan without requirements documents and design specifications. And, Agile or not – these are still really a part of good engineering practice in any discipline. I have been saying for years – “Who would build any building without blueprints???”
  Software projects would not exist with out a customer (internal or external) requirement or a market for a product. Simplified business processes that yield results or Satisfying Leisure computing are the only thing that produce our jobs.
  Pragmatism and flexibility in achieving results while adhering to as much proven best practice as possible given the culture and management are what I have always practiced. Anything else belongs in an Ivory Tower.

• #131 by Mike Gage on August 23, 2010 - 1:43 am

  

  I couldn’t disagree more with this blog.
  I have worked on many projects in many languages. The one I’m currently working on includes millions of lines of code. My experience is that the attitude that unit tests can be optional always leads to problems.
  The people who have told me that agile doesn’t work have not really experienced agile, even though they may have thought that they had.
  I can assure you that Agile works in the real world. It works very well.

• #132 by Dan Kaminsky on August 23, 2010 - 1:54 am

  

  OK, so I’ve spent some time working with a very large codebase.
  The reality is that, once you enter the realm of thousands of developers, if you don’t have test cases you won’t have code that ships. This is because, at that scale, the game really shifts to discovering problems as soon as possible. Each layer always has dozens of other teams who, when they change things, could cause something to break. If that break isn’t discovered immediately by test cases, it’s found at the absolute end of cycle during final integration. By then, it can be way too late.

• #133 by Steve on August 23, 2010 - 1:55 am

  

  I’m afraid my testing practices would horrify a lot of people, but they work pretty well. I may specify test cases before coding, but generally not. My expected test results are almost always generated by running the code. After all, it’s often much easier to verify a result than to work it out for yourself (irrespective of P and NP). I find I get a lot more test cases much quicker that way, plus I almost always miss something working the results out manually, so I’d be throwing them away anyway when the code points out the mistake.
  It’s a bit like those low level design documents, that almost always used to end up being written to match the code rather than visa versa – a case where I’ve long accepted Martin Fowlers view that the source is a design document (but not the only one).
  Coverage stats tell me when I’ve (probably) got enough cases, though there are plenty of cases where 100% stats isn’t enough, and quite a few where 100% isn’t really achievable, and the verified test results get pasted into the regression test code so it stops complaining until something changes.
  This is a price/performance kind of thing. I get a lot of value from writing tests – but you can’t ignore the fact it takes time to write the tests. Toy examples aren’t a problem so long as I can believe they scale reasonably and affordably. I won’t deny that very rarely, I’ve failed to spot an error in those “verified results”, but there’s no such thing as a proof that your code is perfect. Even formal proof tools rely on having some assumed-perfect alternative specification of what your code is meant to do, and frankly, I find it easier to get confused and make mistakes in math than I do in code.
  There’s only one way I can really justify some of these extremist approaches. Given how many developers don’t really test at all, and how many workplaces will ban automated testing as timewasting then throw a tantrum when your slow tedious make-it-up-as-you-go-along manual testing misses an obvious regression, maybe the goal for some isn’t really to get people to do TDD or formal proofs. It’s a neat trick when you can get people to shift their behaviour in the general direction you want and believe not only that it was their idea all along, but that they proved you wrong by doing it. When you say “I got almost all the benefit for a tiny fraction of the cost”, someone may be struggling to hide their smug face.

• #134 by Kevin on August 23, 2010 - 1:59 am

  

  In my opinion TDD is used to drive design, not simply to get a list of green bubbles like some playground attraction as the OP appears to be implying, and contrary to Nathan Manning’s post, under-tested software can occur in any testing environment, it’s certainly not exclusive to TDD but it should be fairly evident from TDD as you’ll have a test/method ratio which approaches, or is less than, 1 as the project grows. Anyway the OP also seems to approve of releasing untested software:
  “Software is shipped with untested parts every day, and just because it’s not entirely tested doesn’t mean it’s bad software or that the untested parts are “useless”.”
  No, but I bet it’s a lot closer to bad software then the tested stuff and if it was code in the auto-pilot of the plane I was about to fly in… Well!
  Agile methodolgies have been used in a number of successful, large and real-world projects, as I’m sure the OP could have ascertained for himself by simply casting around the internet. It sounds like the TDD presenter did both TDD and the attendees a disservice by presenting poorly; however, I’m more than a little suspicious of the OP, who claims to use TDD everyday but seems not to “get” the point of it at all.
  All development practices come at a price as the OP rightly notes, the point is that many software projects hugely blow their budgetary or time constraints assuming they ever get released and then they are buggy and poorly designed. In my experience, working on large, real-world financial projects, Agile and TDD go a long, long way to relieving these problems.

• #135 by Steve on August 23, 2010 - 2:34 am

  

  @Kevin – the author *created* a testing framework. I don’t think his intent is to reject testing – only to point out a false absolute in someone elses argument. His rejecting someone elses claim does *not* automatically mean he’s taking the extreme opposite point of view.

• #136 by Steve D on August 23, 2010 - 2:53 am

  

  I think most of these comments sum up my thgouhts but I will add to them anyways. When anyone starts thinking that 1 size fits all without analyzing the situation you have done a disservice. you have moved away from “engineering”. I like the quote “When all you use is a hammer the whole world starts likking like nails.” Locking into 1 size fits all will never end up with the best end result. As an IT Director I see this in all areas of System and Development. Developers argue their language, framework, and methodology. System guys argue their OS. Whenever anyone argues their point withouht doing any type of investigation I immediately lose interest in that person’s service and discredit their abillity to server our company.

• #137 by rei on August 23, 2010 - 3:37 am

  

  TDD is a haphazard and slow way of figuring out what code has IO dependencies, what has side effects etc. and isolating them. The same thing can be achieved much more easily. Learn a pure functional language and apply that wisdom to your imperative code — and voila — highly refractorable code every time.
  Most people do TDD without having any theoretical understanding of why the resulting code is consistently refractorable. They just do it because it tends to work out somehow. It’s a completely braindead, menial, insulting practice.
  The “confidence” argument for TDD is absolutely weak for this reason. If you understood principles like function purity and side effects, you would be just as confident refractoring your code without TDD.
  Also, claiming that TDD reduces bugs is only slightly better than saying that code that compiles will behave correctly. TDD IS NOT UNIT TESTING. It does *not* catch bugs, save for the absolute most superficial.
  TDD is also a two-fold duplication of documentation: you end up with a test, its function name, and the proper English writeup. Sure, you’re not writing everything in the same way each time, but you’re an idiot if you don’t notice that on an abstract level you’re totally breaking DRY.

• #138 by James Kosin on August 23, 2010 - 3:46 am

  

  I think we are all missing the point. This is really the author’s exceptions to Agile.
  I would have countered that Agile has the customer on site 24/7 to answer any small detail of the specification. Since the customer is the ultimate source of knowledge for the project.
  James

• #139 by Balaji B on August 23, 2010 - 3:59 am

  

  Agile is good for therotical purposes only.
  Till now I have not heard of a single project completed using Agile.
  The so called non-technical english speakers have come up with a concept to keep themselves busy. If it was really that good, the industry would have replaced my favourite water fall model with this Agile.
  But its not. Even after years of its inception.
  What matters is how good software you develop within the deadlines. And not that you deliver a quality software 5 years late than expected with 5 times more cost and loss of business to. It would be useless then.

• #140 by frank1914a4 on August 23, 2010 - 4:17 am

  

  I agree with the author about viewing any methodology as a silver bullet, but some of his argument is just lame and boils down to, “but I don’t have time to do this so let me do whatever I have to in order to meet my deadline.”
  I’ve got news for you, Agile or not, decades of that “I don’t care, just change it” mindset – far more than agile processes – are what’s responsible for the source code swamp many developers have to wade through daily.
  Yes, a lot of Agile/XP practices assume you’re starting a small to mid-sized project from scratch and they don’t scale or graft onto larger legacy environments well. But to discard them as valuable unit test practices because they don’t meet your Big QA Lab definition of System Testing is being just as dogmatic as the evangelists.
  Yes, software of any substantial size ships with bugs. This is where good managers have a role. They understand something many developers are often clueless about: that a dozen bugs in a lightly used functional area with adequate workarounds is less costly to a customer (and a vendor) than one bug in a highly used area with an unacceptable workaround.
  Many low-priority bugs sit in the queue for years because they’re simply not worth fixing – they may be version or platform-specific or the customer base isn’t complaining, doesn’t justify it, or is due to be sunset.
  Like it or not this is a reality of the non-Open Source software industry, no matter how hip or grey-suit that business may appear on the surface.
  (Does anyone still wear grey suits?)

• #141 by David Blake on August 23, 2010 - 4:33 am

  

  Orthodox Agile may work, but I have seen few companies who actually follow all of the discipline required. Is is a downward spiral to cowboy coding. Even if a dev team did everything correctly, in this economy it’s not unusual for entire teams or divisions to be made redundant. How do you rely on pair programming when not a single person is left who worked on the code? Perhaps an out-sourced project is in-sourced, or a project is moved geographically from an office that is getting shuttered. Even an incorrect, out of date comment may be a godsend when you are taking on such a project and starting from zero.

• #142 by Doug on August 23, 2010 - 5:12 am

  

  A grossly myopic and egotistical article.

• #143 by ncloud on August 23, 2010 - 5:58 am

  

  I find good domain documentation to be indispensable because it describes what I need to know about the business. I find unit tests to be indispensable because they help me break dependencies and write terse code. I agree that tests are not a spec. BDD has always confused me because to me, unit testing is about the stability and design of a given slice of code, and not about business rules per se.
  Unit testing can also be very useful in refactoring legacy code. We might have to get creative with interfaces and patterns to make newly tested code “fit” within the spaghetti, but it can work and it can buy you a lot in the long run. I remember gutting a payment processor implementation in a legacy app — I had to wrap the new code in “dummy” classes that still had the same interfaces as the old code, but inside the facade, my new implementation was loosely coupled and tested. My plan was to keep refactoring, little by little, pushing that facade further outward until I had every dependency broken and every class tested, but I got pulled into another project before it could be completed. But the payment processor worked, and never broke after that.

• #144 by tim dugan on August 23, 2010 - 6:20 am

  

  I think this is more of an endictment of agile evangelists then agile itself. “code that isn’t be tested is useless”? Of course not, but it is definitely riskier than code that is. Don’t take the hyperbole too seriously.

• #145 by Jared on August 23, 2010 - 6:21 am

  

  I love the rhetoric sentiment above. “If you haven’t drunk the Agile Kool-aid, you aren’t doing it right.” As if there is “a” way to do Agile. Wake up folks, do what works in your organization or work on figuring out what works and then do that. Agile is not a silver bullet, TDD is not always the best practice, working in absolutes will get you nowhere in software development. The world of software development is subjective, and correspondingly so is development methodology.

• #146 by Samir Bellouti on August 23, 2010 - 6:35 am

  

  I am agilist and I really believe that Agile is a very good methodology. However, Agile does not imply TDD neither does it imply pair programming.
  Agile is about to comply and follow the values in the Agile Manifesto. Other than that are practices that claim to be implementations of Agile.
  I am suspicious regarding TDD and Pair Programming. Even though I am a convinced Agilist (using SCRUM actually), after 14 years working in IT, I find it very hard to sell TDD to managers (cause it has an overhead whether or not some agilists will admit it) and worse, try to sell the idea of 2 programmers working on the same station…
  To finish, one issue I do have at the moment with many presenters at such conferences is that it looks like they’ve lost contact with reality… Same with some authors. We need people on the field 365 days a year to talk about their experience not people reading books or just coming out from Universities labs with no clue about what’s going on in a real company.
  My humble 5c point of view.

• #147 by Paulo Morgado on August 23, 2010 - 6:37 am

  

  And all examples are good only for user code.
  None of the examples and reccommedations are for frameworks that are to be used by unknown developers and where the API is a deliverable.

• #148 by James Walter Taylor on August 23, 2010 - 7:29 am

  

  I think this diatribe has more to do with the wisdom in choosing this particular training, class or instructor. If the instructor can’t give you real examples which nail down the issues you’ve described they are not worth the time you spent.
  The best of agile practices have real descriptions of how they work, how to introduce them to a team, and how some of these real issues of learning curve, new team members, introduction of new practices, u.s.w.; you’re describing an incompetent instructor.

• #149 by Craig Berntson on August 23, 2010 - 7:53 am

  

  I just read this for the first time. It’s right on the spot, but simply saying “Well, if you had started with TDD in the first place, you wouldn’t be having this problem today” is very naive.
  Most of us work on existing code that others wrote sometimes years before, sometimes even before the concepts of Agile, TDD, and unit testing (as we know it today) existed. What we need is better information (articles, presentations, etc) on how to introduce unit testing to these legacy applications.
  Jumping straight into TDD is a bit much for most organizations. I think a different approach of understanding the importance of unit testing and just how to create unit tests on existing code that’s being modified is the right approach.

• #150 by mariangemarcano on August 23, 2010 - 8:08 am

  

  About this “Software is shipped with untested parts every day, and just because it’s not entirely tested doesn’t mean it’s bad software or that the untested parts are “useless”.”
  I think usually this untested software may not have unit tests or functional automated test but It is > 90 % likely that the developer has done a lot of manual / debugging and smoke testing and there is a team of manual testers behind on the component they are building, wouldn’t be nice if this test where reusable in the future?
  I agree in the part that the Agilists should work more on present more realistic scenarios and how to deal with tone of code that doesn’t have reusable test, and the fact that the project’s needs varies a lot.

• #151 by thadb on August 23, 2010 - 9:06 am

  

  I have seen some companies use Agile and do it well, but it is not the “end all, be all” of development. It also took a lot of pain to get there and now they are locked into the Agile method in it’s entirety. If it ceases to work for them they will have to go through a lot of pain to get out of doing the entire Agile model.
  In my current job, we employ some Agile practices, but only the ones that make sense for our company. The more I have studied and looked at all the different methods out there the more I’ve become convinced that custom made processes, tailored to the companies culture, make the most sense. I try to stay away from becoming dogmatic about any one idea, but I’m buying more and more into the Context-Driven typology all the time.

• #152 by Richard on August 23, 2010 - 9:21 am

  

  Re: Post 30 by Nathan Manning.
  Agreed.. there is a common mistake that is made by engineers (and managers) on both side of the Agile argument.. they mistake tools and process for discipline when THEY ARE NOT. Common sense and good discipline make things better, but are rarely practiced in any organization I’ve been in. You can apply this to all the disparate comments made for this blog entry. Nothing is a replacement for discipline, and with good discipline many processes can be made to work well.
  I’ve used TDD for 15 years now, thinking in terms of unit testing for many years now and tend to have very few bugs occur. I managed at Oracle for quite a few years where we had very fast turn around releases that some folks might call sprints.. but where we were using what folks would call waterfall style documentation (design docs kept up to date, formal design reviews, etc.).
  Folks take both sides religiously, but when it comes down to it, these common sense details will prevail:
  o Customers like to change their minds after they see stuff, so plan for that.
  o Thinking out designs ahead of time is better than just coding.. I’ve seen too many folks paint themselves into corners that could have been avoided by designing and analyzing up front.
  o We don’t always have the monetary luxury to have two programmers working on the same piece of code
  o Good (and maintained) design documentation protects against programmer turnover.. and every programmer who has been around knows that its one thing to read the code, but if it is truly convoluted puzzling out what it should have done based on previous requirements, absent of documentation, can be an exercise in extreme frustration. If the one guy that wrote it is gone, you can be truly in the hurt locker.
  Again… the common idea behind all this is good discipline.. and achieving good discipline in an instant-gratification style world is the TRUE challenge. Agile vs. Waterfall is a theoretical argument, the real world challenges us with problems that don’t neatly fit into either.. which means look, adapt, and react in a disciplined manner. THAT is the path to real project success.

• #153 by Sean on August 23, 2010 - 10:34 am

  

  @Balaji B,
  If I were interviewing you for a job, asked you for your thoughts on Agile, and you told me that you have never even heard of a an Agile project that was successful, I would thank you for your time and show you the door.
  It shows that you don’t really have much professional experience, or you are so set in your ways that you will be dismissive of any counter-evidence.
  There’s really no point in listing out the ever-growing number of companies who are transitioning to Agile and seeing good return on their decisions in the process. You will just blow it off and keep doing what you’re doing.

• #154 by Cedric on August 23, 2010 - 10:41 am

  

  Sean Art: Is it really the candidate’s fault if they have never seen a successful Agile project? It feels like you are filtering out candidates on criteria that are completely out of their control, a bit like judging someone based on their skin color or where they were born.

• #155 by David Cuthill on August 23, 2010 - 11:04 am

  

  “Agile” people still don’t get it!
  I’m with you there:
  The problem is, they Don’t get “Agile” either..
  “Agile” seems to be a re-tread of the production manufacturing methods we used in component manufacturing in the 1980s at National Semiconductor. And that was a J.E.Deming re-vamp of USA WW2 production methodology that was re-learned from the Japanese who picked it up in the ’50s.
  We supplied components to the mainframe manufacturing plants at IBM in France. They wanted zero production defects, and achieved that. There was no incoming inspection testing of our components or their circuit boards on their production line. Our components were supplied at a failure rate of 0 parts per million. (Obviously we production-tested 100% and then sample-tested the hell out of them prior to shipping). The program was called “Ship To Line” where the components came off the delivery truck and went straight to their main board assembly in a Just-In-Time kanban system that made circuit boards to very short product runs in a sales-order-driven line. Win-Win because we sold standard parts on huge mark up based on the added value to the customer of not needing to test, or keep stock.
  Software Production:
  I guess – in Agile- they are trying to work software production in a kinda Kanban way (Kanban is where the production line pulls all the way from the orderbook not pushes based on some production quota).
  A software product (as opposed to a system) is issued on a release schedule – a bit like components coming off a production line I suppose. I like the concept of scrum-agile where there is a flexible backlog of requirements, a stack of finished code modules ready to be assembled, and the spec is only set in stone for the next release during a 2-week sprint.
  As with all these schemes, the entire system becomes a lifestyle akin to a cult. Many of the consultants have never worked in it for real. They are more like groupies.
  One thing needs to be created in the customer’s mind. Value. If they want to be lazy and indisciplined about requirements – fine. But they have to be made to pay more for that. Work to a 2-week sprint assembly of code modules that can be changed in backlog? – better. That allows it to be done less expensively and their price is less. That is Win-Win.
  Components of whatever nature need to fit. They need to be pluggable and replacable, forwards and backwards compatible without complete system retest.
  These can’t be made as 1-offs like a piece of art and then fettled-to-fit.
  It isn’t so much “Waterfall vs Agile” but “Engineered to fit” vs “Sculpted like art”.
  Agile is a way of life – not some optional training course you send individuals on. Everyone must be signed up to it, live it, think it, dream it and make it work. You can’t think you are “Doing” Agile and then say “Sorry – pair programming is too expensive”.
  “Agile vs the ‘Real World'”
  Agile and the other cultural approaches seek to redefine the real world. The real world is a cold and friendless place where young coders’ energy is traded to prop up indulgent, sloppy practices, billion dollar software projects fail and Individuals are bullied into committing to ridiculous deadlines that nobody believes in – and-it costs minds and bodies. Changing the culture with semiconductor parts was a great experience I participated in, it worked superbly well and was good business.
  I’m hoping for great things from Agile-scrum. I just hope I’m on the winning side in the rough Rugby game they call working in Software Development.

• #156 by Stack on August 23, 2010 - 11:12 am

  

  It sounds to me like this presentation was actually on the very specific “Test driven development” style, not on “Agile”

• #157 by Talbott Crowell on August 23, 2010 - 11:25 am

  

  Your claim that agilists “never — ever — disclose the risks and the downsides” may have some truth to it, but whenever you are advocating in a significant change in methodologies (for example from waterfall to agile), it can be difficult to gain corporate stakeholder buy in when you focus on the disadvantages and failures.
  Four years ago, Kent Beck responded to a similar challenge in an interview posted at:
  http://www.infoq.com/articles/kent-beck-interview-2006
  Kent Beck: “And yes, people in the agile community jump on you as a failure when you admit that things went wrong. This fear reaction keeps us from a lot of useful learning.”
  A methodology such as agile (be it XP, Scrum, or a combination) and agile practices such as TDD, continuous integration, quick turnaround to customer, have pros and cons. I have found the biggest challenge in getting a team to adopt TDD is dedication and skill. Sometimes your team just needs to get their job done and TDD can appear to add more work to their plate. Once the tests start getting stale and breaking and if only some of the programmers are writing tests, then the managers end up supporting the disabling of test in order to move forward.
  TDD requires a lot of discipline and skill. Often developments teams are not made up of expert programmers. And sometimes expert programmers can even resist because they have been successful without TDD.
  In the real world I agree with Nathan, TDD is not a silver bullet, you need to practice “good discipline.” If you can integrate TDD into your team in a disciplined and healthy way, then your team will probably benefit. TDD is not new, but it has recently become more popular, and in many firms, standard practice. I am a big supporter of TDD and have personally seen the benefits, from small projects to huge enterprise applications running Fortune 500 companies.
  My recommendation is that you explore it if your team is willing and learn from it. If you don’t like it, don’t use it. But don’t blame the agilists for not giving you all the downsides, instead see for yourself. Your will learn the downsides and challenges of implementing TDD pretty quickly.
  Here are some of the things I like about TDD:
  1. Interruptability: if you write a test first, and you get pulled away to a dreaded meeting, you can get back to work faster because you simply rebuild and run your tests to remind you of what is next and exactly what problem you were trying to solve before you were pulled away, since you wrote the code that would fail until you implemented the solution.
  2. Less fragility: I’m less concerned about fixing and refactoring code when I can rerun the tests before checking in. Sometimes in large complex enterprise projects, a small change can break some distant dependency. We’ve all been there where we are afraid to make a change to someone else’s code because the app is so fragile. TDD reduces stress and makes programming more enjoyable.
  3. Refactoring: a benefit from #2 is that you can keep a clean house. Nothing worse than code that “smells” and is not fun to debug or navigate. TDD allows developers to constantly refactor and delete dead code so you don’t have an increasingly growing pile of dung. It is much more fun to maintain a codebase that is 25% of the size and clean.
  4. Less time wasted: when a test can pinpoint a bug in seconds that can take hours without test coverage, you realize that TDD can often reduce the time to develop software over the course of the project.
  Disadvantages/Risks:
  1. No buy in by developers or management: this is the biggest risk to TDD. If you don’t have people who realize the benefits, it will never work for your team.
  2. Dependencies: TDD should be implemented in a way that has minimal dependencies. Depending on a database connection, network connection, web services, etc.. can lead to fragile tests. There has been a ton of work in this area, especially mocking frameworks, to get around this issue. Done right, your tests should test only your logic, not external components.
  3. Hard to add TDD later: TDD is best to have in place before you start coding. It is very difficult to add TDD to an existing project. Often the application architecture will evolve in a “testable” way when you are using TDD. You will write your code and use application frameworks like ASP.NET MVC instead of ASP.NET WebForms for example to make testing easier and more natural.

• #158 by Sam Goldberg on August 23, 2010 - 11:29 am

  

  I have been using TDD/Agile for the past 8 years. I have *only* on real projects, enterprise applications. Not only that, I’ve done production support, so I understand what it’s like to have things go wrong in production, and have to figure out from code and logs why something didn’t work.
  TDD is not about a “fuzzy feeling”, it is about proving that a section of code does what it is supposed to. Writing code without tests is like tight-rope walking without a net. There’s a chance that you’ll get it right, but if you don’t there’s nothing to catch you. I can think of a number of times where code went into production, where developer made simple error of returning the opposite boolean than intended. (a very easy error to make).
  “Agilists just don’t understand the meaning of calculated risk.” I think you don’t understand the meaning of calculated risk. I work on trading applications, where a simple error can result in large dollar losses. Unless your users have a high tolerance for programming faults, you’re better off not shipping untested code.
  And in large applications, of the sort you claim Agilists don’t do, often have code which is very hard to reach through conventional functional testing.
  Agile/TDD practices don’t solve all developer problems, but they solve a lot of them. (How about instant regression testing, code branch merging, etc?)
  I recommend using the golden rule when it comes to testing: You only have to test the things you want to work.

• #159 by Gary Woodfine on August 23, 2010 - 11:35 am

  

  I must say that I totally disagree with the notions in this post and a majority of the comments. There seems to be the perception that “Agile” is nothing more than Unit tests and leaving comments. When nothing could actually be further from the truth. Following this logic most people who left comments here opposing “Agile” would probably deduce that “Agilists” don’t need a specification before they start coding. That my friends is not “Agile” that is “chaos”.
  Agile is a methodology, and like any methodology is open to corruption and misimplementation.
  As a freelance agile developer, I have yet to actually work in an organisation that has actually fully implemented the Agile methodology correctly. What they have actually implemented is an “AgileFall” and alot of misunderstandings.
  I will probably in a couple of days post a reply blog explaining exactly what I mean.
  @RoobNoob keep taking those pills dude, and when the men in the van with the little white jacket show, don’t fight them off.

• #160 by Philip on August 23, 2010 - 11:37 am

  

  Surely the problem is that he had a bad experience with poor a poor traing company / presentation.
  The guy has been a victim of the untrained trainer training course, wherby some outfit has simply added an “Agile ( Test-Driven Development presentation)” course to their portfolio, read a few books and tried to give a course. The students are then simply victims of the bad information.
  Some interesting comments though.
  He’s at stage 10, with the trainers somewhere at stage 8/9 [see http://www.stsc.hill.af.mil/crosstalk/2003/07/sheard.html Life Cycle of a Silver Bullet]
  Philip
  [Systems Engineer]

• #161 by Laura on August 23, 2010 - 12:45 pm

  

  BRAVO. Thank you for this article. Great insight and loved the reminder that software development for the ‘real-world’ is never black and white.

• #162 by Ricardo on August 23, 2010 - 12:56 pm

  

  The one thing I got from this is something I already knew. There is no silver bullet.
  Techniques are just tools. Just as you won’t use a hammer where a screwdriver is needed. You won’t use technique A when B is needed. Nor will you build a building using only a hammer. Design and testing are both needed in engineering. Software is a bit more difficult as we also require capability for expansion for technologies we don’t yet know. So documentation is not optional.

• #163 by rei on August 23, 2010 - 2:57 pm

  

  I don’t know if one can be blamed for misunderstanding what Agile is.
  As far as I can tell, it’s a set of ideas, many of which are common sense, many of which are utterly perverse. People end up picking at the worst ideas to criticize it and the best ideas to pitch it.
  It’s like the “cloud” hype. Maybe a few people out there have a coherent idea of what it is, but even if that has merit, it neglects the fact that on a societal level it won’t work, for the exact same problem that Agile tries to solve in the first place: we can’t achieve perfection.
  Ideally you’d take the Agile ideas that work for you and leave the rest, but if cherry-picking Agile principles results in dismal failure as some of the Agile practitioners here point out, then in the bigger picture, Agile should not be encouraged.

• #164 by Kevin Nelson on August 23, 2010 - 2:58 pm

  

  Tests like all programming can be written poorly. You can have bugs in your unit tests. Poorly written tests can be long and laced with dependencies that make maintaining the tests a nightmare.
  I’m in a .NET project that started a year and a half ago, which has dependencies on Entity Framework scattered throughout the application, which is causing scalability problems. Due to all the dependencies, it’s been decided to start from scratch rather than try to re-write the code. However, TDD was not used for this project, and I can’t help but think that if TDD had been used and enforced, it would have pushed the project to be more loosely coupled, and a complete rewrite might not be necessary.
  Really, the problem was lack of IoC more than anything else, but since tests encourage loosely coupling, it is a step in the right direction. So, I’m not opposed to companies being religious about TDD, BDD, or DDD. However, as stated, these are just tools that can help (not force) developers to adhere to good practices and reduce (not eliminate) bug counts.

• #165 by Rodrigo Silveira on August 23, 2010 - 5:54 pm

  

  From ’01 thru ’08 I managed a software engineering organization responsible for maintaining and enhancing a marine container terminal operating system; it supported the planning of the unloading/loading of vessels, yard management, supporting a variety of complex set ups (RTG, Straddle, Chassis, automated, etc). In addition it offered sophisticated vessel scheduling, and yard allocation, and truck optimization capabilities. It consisted of north of 2 MLOC, was started in the late ’80’s, written in in Apple PASCAL, converted to the PC, and later ported to C++. Get the idea! It was as real of a beast as you can imagine. No one knew how it worked!
  It took years, 2 to 3, before an good engineer could do work on it worry free; exceptional folk were able to do it in less time. Eventually we hit into the idea of using TDD to help us out. We automated 180+ manual tests suites and declared that they established how certain features worked; if anyone asked how certain functionality worked we would refer them to its test suite/s; yes, yes, yes, I know that this was not the case, a lot of untested code could be there, but it did not matter since no one knew about it! The tests became the documentation. Eventually we had over 700 tests that required a lot of HW to run in less than 4 hours.
  New engineers used the tests to “play” with the app and learn it; customer support folks used them to assess problems in the field., etc. Our CSAT went from less than 3 out of 5 to 4.2+. I believe the automated tests had a significant impact on these results.
  Now, was it Agile? I don’t know. The point here is that these fads have good and bad things. It is up to the practicioner to understand what these concepts and tools can do for them.
  Overall a positive experience.

• #166 by Alchemist on August 23, 2010 - 8:37 pm

  

  The Agilists are often evangelical cultist zealots who will go on a witch burning if there is someone who “doesn’t get it”. Kudos for fighting back. I’ve seen people destroy projects by using the creed as an excuse to not document or comment, and just run ahead at 200 mpg until the project was destroyed in a fiery crash as road-kill on the Agile autobahn.
  The founders are making tons of money promoting their system with exaggerated claims of 1000% “Productivity” gains.
  Also, for those who talk about the Agile “methodology”–I’ve read the founders specifically calling it -not- a methodology, but a certain set of techniques for dealing with complex systems.
  In the job market right now–generally speaking, if you don’t act like Agile and design patterns are the new religion, they act like you’re stupid, so everyone pretends to know something about it…not sure that many really get the main points and are able to use them effectively.
  It did just dawn on me the other day, the thing about people over processes…that’s actually kind of cool.

• #167 by Per-Magnus on August 23, 2010 - 10:43 pm

  

  Having been a “saved” agilist from some 15 years now I must admit the article has some good point. There are som good counter-points too. In agreement with the article author I’d say …:
  – a few lines of code documentation, especially on the over-all algorithm goes a long way towards understanding code quickly and does not take a long time to deliver as you are coding. Agile does NOT say you should not do this. Some overly zealous agilists may, but there is no general agreement.
  – agile does NOT say no documentation (it just says oral communication is usually preferable), in fact – agile mostly talks about documentation of requirements and how almost pointless it is to trust written big up front specification documentation. There is no general agile view on how well to document the system itself or not. This is really up to the product owner to decide.
  – if you do all with user stories that you can including acceptance criteria, there is actually quite a bit of “specification” for just a 40 hour work item – the big difference we don’t do this up front before we start we do this while we are working supplemented with lots of oral communication and discussion, just in time – not ahead of time.
  – agile done properly is far more disciplined than any specification driven process I’ve ever seen – we just have discipline as we go, rather than up front before we start walking. Discipline, discipline and discipline again is the way to succeed with agile. Coaching clients this is one of the most difficult cultural changes things to understand and make happen – agile requires far more discipline than they’ve ever seen before. And involvement, focus and fun.

• #168 by Uncle Bob on August 24, 2010 - 5:00 am

  

  My response in 2006 still applies today, though FitNesse has grown to nearly 70,000 lines of code. http://butunclebob.com/ArticleS.UncleBob.AgilePeopleStillDontGetIt

• #169 by ed neff on August 24, 2010 - 7:33 am

  

  agile is nothing more than repackaged common sense for most experienced developers no matter the language
  it proves the adage that “what’s gold is new again”

• #170 by ysap on August 24, 2010 - 2:16 pm

  

  Admittedly, I don’t really know what Agile is. I think I got some sense from reading this post. However, one thing that immediately occur to me is your point about “If it’s not testable, it’s useless”. Well, your examples suggest that you completely missed the point. Note that no one says that if it is not TESTED, it is useless.
  But really, if your code *cannot be tested* (i.e. is not testable) for compliance with the spec or the definition, it means that you don’t have a WAY to KNOW it is correct. Even not theoretically. Then, what use does it really have?

• #171 by Charlie Cole on August 26, 2010 - 8:25 am

  

  “If it’s not testable, it’s useless”
  Hi,
  Having spent all week trying to use 2 commercial codes that have more bugs from lack of testing. I believe that codes that are not actually tested waste countless hours for real people that are trying to use your codes
  The other main advantage of an Agile development is that you, when followed correctly, end up with a code and user interface that is actually useful to the end user and does not subject them to unnecessary burdensome point/clicks/reformatting inputs/steep(almost unclimbable) learning curves GUI’s. The problems with the standard approach is that it builds in difficulties that can not be easily re-engineered.

• #172 by shinta on December 9, 2010 - 8:57 am

  

  Totally agree here with you on the article. Some Agile practices are not very practical and real. You just need to adapt them to your team. As with any advice, methodology, we have to use what makes sense and ditch the rest. 🙂
  That’s my motto!

• #173 by Mario on December 20, 2010 - 10:34 am

  

  I think you are confusing “untestable” with “untested”. They are not the same thing. Untestable means no test can be devised to test something. Not tested means simply no test was executed to exercised a peace of code.
  Honestly, I don’t think a lot of people write untestable code. Code that runs in conditions that are extremely hard to reproduce in non-real world environment/data set etc.
  I don’t think anyone disagrees with you on shipping untested code. But it’s not the same as untestable code.

• #174 by PM Hut on December 28, 2010 - 2:08 pm

  

  The problem is that some, not all, have interpreted Agile as a cult, and are now trying to spread their beliefs.
  Some people say that Agile is nothing more of a scam (this is not my personal opinion), in order for some select few to gain fame and to create a market for Agile consultants.
  “Stack, List, Money, Bowling” – I agree about the not-so-convincing examples in which they see Agile as a good way to manage projects.
  Maybe check this? http://www.pmhut.com/fr-agile

• #175 by TomG on March 22, 2011 - 7:03 am

  

  I’ve been practicing Agile for a couple years now, and I still can’t get my teams to adopt TDD. They are, howevere, writing functional and unit tests. I’ve always liked TDD as a concept, but putting into practice is difficult.
  I really like Agile, as it’s more predictable than traditional project management. I think the key to my success with it is that I don’t have any non-technical project managers on my team.

• #176 by E R on October 23, 2011 - 10:36 am

  

  Nice write-up, nice to see it’s still getting traction (and comments) so many years subsequent to its posting. Yes, many Agile “practitioners” are treating Agile as a cult, with dogmatic (and naive) ideas and with arbitrary, unproven (and sometimes ridiculous) assertions presented as the-one-and-only way to succeed. TDD is a technique/approach/pattern like any other, helpful in some cases, useless in others, worth having in one’s toolbar in all. Presenting it as a commandment is, well, indeed childish.

Comments are closed.