Myself and my code included.

In agile especially, no code is written that the customer didn’t ask for.

I suggest doing a bit more research before criticising a methodology that your company advocates.

The second point, that developers can get attached to the code they write, is mitigated by promiscuous pairing (changing partners every day) and collective code ownership. It is not my code, it is our code. Furthermore, requirements can change overnight, and features get cut or added regularly, so get used to it

Jim

The development model I like best is Rational Unified Process, for a couple reasons. First, one of the primary goals is stability. Every iteration in a development cycle should end up with something very stable to minimize errors and force advance planning. I have found through my own project work since coming to the school that this tends to leave a programmer with the perception things are slow, at least in the beginning, because you can’t show as many beeps and whistles to a client (or boss) as you work on all of the hidden things that go into creating a stable platform.

The second thing I really like about it is its flexibility. It can become a very high ceremony development framework, with lots of documents and sketches, or it can easily adapt to smaller projects by asking only for the documents that support that project. A lot of corporate development seems to put the ceremony ahead of the process, or confuses it outright with process.

Agile seems to be the same kind of framework, except that - as you point out - there is an emphasis on completing small features that may not even be required. I would think the positive spin on that is the experience the programmer gains from the process of doing so much building. But it is a prerequisite for the programmers to view these mini sessions as the equivalent of a designer’s concepts - disposable and part of the process

Secondly, I fear any situation where developer start writing code before the customer figures out what they want. In my opinion, the role of a BA is to help explore this situation with the customer, and co-ordinate the generation of stories.

There shouldn’t be a situation (like the one you describe) where developers just feel what’s write and offer up solutions. In a ‘classic’ XP team where the number of people is small, it’s possible to have everybody sit down with the customer and a white board and sketch out and talk through ideas. During which the devs (at least in my experience) question the customer about what they want - the rule of the 5 whys. Attempting to understand the _actual_ problem at hand, rather than what the customer says they want. They can be subtly different.

As you say, nobody likes to throw out work, but in my experience by having these discussions earlier with _everyone_ people are less likely to make bad assumptions and spot opportunities to deliver value sooner.

At the risk of sounding repetitive, there shouldn’t be a situation where a developer just sits down and starts coding without attempting to deliver some business value - the story. The more often (and quicker) you get feedback, the more likely you’ll be to not spend time writing something that isn’t needed.

Good point and a valid concern. However, in my experience the scenario that you have described has never happened. I think that there are many reasons for this, but I’ll highlight just a few.

1) In most cases, a high level story list will already have been created, so the developers will have a general idea about what is needed and what is not. This is also a time where you need to trust your BAs, they have a pretty good idea of what the business wants and needs. By all means ask questions about the specifics of the implementation do they need real time chat or will email do? But if there is a requirement for communciation of some sort your efforts are not going to be wasted.

2 & 3) This scenario is where the other Agile practices come in to play. Having collective code ownership means that no one developer is going to own a piece of code so it’s not going to be such a wrench to lose it. Having an iterative approach to development means that if the customer changes their mind, or a new requirement is discovered, the amount of work you are going to lose will be one, perhaps two weeks, but at least the customer has been able to tailor the solution to their needs.

Now is the time that I make the mandatory reference to Kent Beck’s Extreme Programming and set you a challenge - have a look through and see where any of the other practices help to mitigate the problem you have described.

Cheers,

Tom

To sum up, someone has to ask for the feature before you build it.

Now this doesn’t mean that you can’t build a quick prototype to demonstrate a potential feature. A recent example is just showing people what script.aculo.us makes possible. However, developers don’t prioritise features.

I do find that a sense of detachment is useful though. Creating useful things tends to be more about removing things than adding things.