Dave Thomas says, "A prototype is like a town in a western movie. It's all facade. There's nothing behind it. You cannot move in a raise a family in one of those houses."

Read this Artima.com interview with Pragmatic Programmers Dave Thomas and Andy Hunt:

http://www.artima.com/intv/tracer.html

Here's an excerpt:

Dave Thomas: The software analog to firing heavy artillery by calculating everything up front is saying, "I'm going to specify everything up front, feed that to the coders, and hope what comes out the other end is close to my target." Instead, the tracer bullet analogy says, "Let's try and produce something really early on that we can actually give to the user to see how close we will be to the target. As time goes on, we can adjust our aim slightly by seeing where we are in relation to our user's target." You're looking at small iterations, skeleton code, which is non-functional, but enough of an application to show people how it's going to hang together.

Basically, it all comes down to feedback. The more quickly you can get feedback, the less change you need to get back on target.

What do you think of Dave and Andy's comments?

It's a nice metaphor to what all agile methods propose. Building your functionality gradually and getting frequent feedback.
I'm working currently in the very "waterfall" environment. Based on my observations here I was wondering how applying agility would put most of the business/system analysts out of the job. What is the place for such people on XP/Scrum projects? What Dave and Andy think about it?
The company I work with right now does not fire people, so they would need to find them a place if they ever go agile (which I doubt ;) ).

-- Krzysztof

There is much truth to your summary line "The more quickly you can get feedback, the less change you need to get back on target."

That is if you can get feedback when it would be optimal to get it.

My experience is that the feedback does not come when the prgrammer needs it. You ask and ask and get very little. The moment your software goes live, than the feedback really starts and all in short order and expecting an immediate instantaneous turnaround with the undertone of "I can't believe they did not know I would want it to do ....., I thought that was obvious............."

> Based on my observations here I was wondering how applying
> agility would put most of the business/system analysts out
> of the job. What is the place for such people on XP/Scrum
> projects? What Dave and Andy think about it?


I (Dave) currently believe that most job titles are artificial: no person is just a programmer, or just a designer, or just a business analyst. Instead, everyone performs a variety of functions. Perhaps the more junior people feel more comfortable in the more directed and immediate neighborhoods, so they may spend more time at the low levels. But as their experience grows, then what they do day to day gets fuzzier ("Hey, Ma, look at me. I'm designing!").

So, the answer to your question is that I believe that most of these roles get assimilated back in to the team: if these folks have a positive contribution to make then they should be welcome there.

Cheers


Dave

> Instead, the tracer bullet analogy says,
> "Let's try and produce something really early on that we
> can actually give to the user to see how close we will be
> to the target. As time goes on, we can adjust our aim
> slightly by seeing where we are in relation to our user's
> target."

As described in this interview segment, using "tracer bullets" (rough working code that implements a requested feature) is a good way to get early warning of changes that the client may wish to make in the final product. From what I understand, frequent meetings with the client to show the current working software is a tenet of agile software development. But, earlier in this interview series ("Orthogonality and the DRY Principle"), Hunt & Thomas recommend taking such steps as building a code generator, or taking care of some infrastructural issue early so that it does not become a problem later.

I'm not arguing with either approach, but it seems that these two recommendations are fundamentally at odds. In agile software development on the one hand, the idea is "don't build something until you need it, because you probably won't need it, or even if you do, it might be different than you expect". This makes a lot of sense. But the earlier recommendation of anticipating what will be needed and building a solution ahead of time also seems to make a lot of sense -- yet these two approaches seem mutually exclusive. What do you think?

(I'm not asking this to be belligerent; I'm genuinely curious about this since I read about agile programming in Robert Martin's book at the same time that I read the "Orthogonality and the DRY Principle" interview, and was struck by what appeared to be a conflict in the two. If I'm wrong, please don't hesitate to explain how. :)