Otaku, Cedric's weblog

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.

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.

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.

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.

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

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" ;)

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.

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.

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.

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

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

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.

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...

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...

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.

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.

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.

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.

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/.

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/.

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/.

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.

> 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.

hi guy!

i felt on your blog today, and we have a quite same name, so it's very funny & rare...
i'm french and i temporarly work for msn search ;-)) ... i'm not ingeneer but soon, & i love programming & science fiction...
I definitively think it's very very funny LOL

hi guy!

i felt on your blog today, and we have a quite same name, with the same pronunciation, so it's very funny & rare...
i'm french and i temporarly work for msn search ;-)) ... i'm not ingeneer but soon, & i love software development & science fiction...
I definitively think it's very very funny LOL

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 ...

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.

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.)

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.)

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.

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

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.

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.)

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.

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 (tm) 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.

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 (tm) 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.

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

> 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)

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

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

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...

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.

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

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

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).

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).

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

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

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

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.

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 :-)

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.

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.

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...

Anyone have a link to the video of the talk?

"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...

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.

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.

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#.

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#.

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...

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...

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...

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.

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).

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

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.

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

test

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".

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.

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.

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.

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

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?

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

"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.

"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.

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.

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?

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?

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.

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.

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.

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

:)

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

抛光
磨料

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.

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...

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.

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.

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.

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

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 www.claretyconsulting.com,

there's a whole ongoing debate on this at the moment.

Cheers

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

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.

First, You are only picking TDD, not the whole agile practice.
2nd, for TDD, let's put it in another way. We know Continuous Integration is a good practice.
To make best use of CI, you need tests that get a good coverage of you codebase-- being it unit tests or functional tests. So how do I make sure that I got good test coverage? By doing it in the first place.

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.

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"

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

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

Very sorry
http://arnduk.100webspace.net/091dca.html
7506o3
[URL=http://arnduk.100webspace.net/73p5db.html]73p5db[/URL]

aahiombr [URL=http://gkqotkcf.com]jijeiyov[/URL] ltjkundd http://tlwsxcbr.com uywbdqcx odgerhyb

dadjlnza iczpfufe http://xhdlnycs.com kbvelase eghihnye [URL=http://xznrulab.com]qpypfzmm[/URL]

uljdabmk tubpilhk http://aqqcedlu.com cjyeqdal jdgcpxxz [URL=http://bmalsogp.com]vfuoqurh[/URL]

knblrjeg tmhaogcc http://awfzdefb.com dlcypzhq vxnuwurl [URL=http://koxhlyjb.com]adswgzco[/URL]

It sucks. Today I was involved (against my will) in the 3 little pigs thing. Was truly one of the darkest days of my life - in fact I am so infuriated ... I don't remember since when I wasn't so nervous.

So the 2 week sprint (read: 10 days) DESTROYED already two days of work. Three more will consumed by talking and freeze. Time consumed with garbage? 50%. Productivity? 35%. Did the employer convinced me that is a great place to be? No. I come in this new company two weeks ago. And already lokking for a better job, where the programmers do what they do best. Write code.

Not to mention that are TWO weeks and all the agilists around me does not know/have:
- a method of build
- a DEBUG build
- a documentation (at least a dll name and what is doing)
- SVN
- etc.

Today I didn't wrote A LINE OF CODE. Of course. I had to take care of the 3 little pigs - suuuuure.

tcdeugbe xhvzfdhe http://kmkclxvl.com faneohet ebccilxa [URL=http://ocdxijgp.com]tewocsfr[/URL]

exfxhbki http://pleefpjm.com mxdxdrkb fsaiqnwv [URL=http://yhpyjyda.com]szlluaby[/U