I'm not against agile/TDD and use it under most circumstances. However, in some circumstances I feel it doesn't work well.
For example, the other day I was building a fairly complex data processing app. In an ideal world I'd layout the foundation, design the components, write unit tests and demo on each sprints as I finish "features". In practice however, I don't think this works before the first version is released because:
- The foundation/component design changes frequently as I figure out
how to do things better, and simple test drivers are much more useful
than richer unit tests
If you are building a MVC app., the foundation isn't going to change, but with an app. where you more or less build the framework yourself, and don't quite know how to do things best beforehand this isn't the case. I feel simple test drivers with no automated verification are much more useful than richer unit tests at this stage.
- Until the basic infrastructure is in place, it's hard to break
down things into individual "features"
If you already have an MVC framework, this is easy. But imagine how the the first MVC framework ever was developed. It must have been much less useful to think things as individual "features" in the initial stages, because the most important thing was to work out the principle and philosophy of separating Model, View and Control, and how to do that.
- Demos help very little until a sizable part of the app. is done
In a UI, you can just put up a mocked up interfaces and get lots of valuable feedback. However, e.g. in a web crawler, you can't really do a meaningful demo to non-technical people until quite a bit is done, and even if you did, they usually won't be able to give useful inputs anyway. Sure, you can demo to your developer colleagues, but it's hard to give input based on some log output. It's usually much more productive to explain how you did things and how you plan to do things perhaps showing illustrations and code, and get feedback this way.
Or am I just doing it wrong?