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?

  • -1 You're conflating Agile and TDD. Aug 15, 2013 at 9:52
  • 1
    I like when people downvote when they think the OP doesn't understand something as opposed to give useful answer or input because that's totally the point of a Q&A website. Aug 15, 2013 at 19:38
  • "agile/TDD" is not a real thing. Agile is a set of values (note my capitalization of A), TDD is a specific development practice. Yes, you are just doing it wrong :P. The point of this Q&A site is to promote high quality questions and answers through the use of votes. You got a down vote for making up new things. As its a concept you invented - it wont apply to anyone else. Fix the question and I might consider changing my vote. Aug 16, 2013 at 8:21
  • @DaveHillier: I find it weird that a criteria of a high quality question is good understanding of the concept that are being asked (after all, if the asker understands it, why would he/she ask?) but fair enough, the community shall decide what the criteria is. Aug 16, 2013 at 11:02
  • Writing the perfect question - Jon Skeet You shouldnt have to read much of that to understand why I downvoted. Some simple first steps that might help are to look at the wikipedia article on Agile and the one on TDD Aug 16, 2013 at 11:46

1 Answer 1


You seem to be developing in a very agile way, actually. A non-agile way would be to spend weeks drawing the design on paper and sticking to it when you program it and (inevitably) find that the whole thing is a house of cards.

That is speaking about the general principle. For the concrete meanings of the terms like test driver, demo, feature etc. they are specific to the situation.

They are always specific to the situation. The common meaning is the one applicable to the most common kind of application, which is business information system. That kind of application has a generic foundation that you already have and on that are built individual forms, reports and workflows, that can be added one at a time. So you can add the few most basic things, demo it, than add some more, demo again etc.

But there are many applications where that is not true. You can still use agile process, but kind of internally in the project. Your "user" stories become defined in terms of programming APIs implemented, your tests test just those raw APIs and such. It is agile process in the sense you implement the minimal functionality for each component and refactor it as you need more functionality from it, and it may be test driven in that you have unit tests for the components. You just don't have the eventual customer involved (yet), because you have nothing to show them. You eventually will and than you'll still be refactoring the foundation, because some fundamental problems can still appear than.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.