Conversations and Deeper Issues

Brian Marick writes about Story Cards which contain only the name of the story, thus encouraging developers to talk to the customer before writing code.

This resonates with me for two reasons.

1. I have seen "agile" projects start out by writing story titles on story cards, then add "supplementary" MS Word documents, then write even more bloated documents etc, and then people start saying "but that is not in the document" ,"let us update the document" etc.
2. These days, I am very leery of what I see as an artificial split between "analyst" and "developer".

Don't get me wrong. There are people who know particular domains well and if you are lucky to have such people on board, they are worth their weight in gold. But, and this is very important, an analyst is NOT the same thing as a domain expert. The set of genuine domain experts and the set of so called "business analysts" rarely intersect.

What turns me off is the blurring of the distinction between a genuine expert and someone who comes in and "models" the domain. The idea that someone can become an analyst just because he has an MBA and then spend his time writing ever more baroque MS Word documents/Excel sheets etc, with no real responsibility for the code is ridiculous. The person who analyses the domain and the person who writes the code should be the same. If a software "engineer" can't do this he has no business coding a solution for that domain.

Now, a lot of developers don't care about how business works. This is often because the domains dealt with in "enterprise" software (insurance, leasing) etc, particulary the dreary parts that wash up on the shores of India, are desperately boring to a technically focussed developer and so he refuses to look more deeply into the domain and then pays the price by having to work off an endless stream of word documents.

The easy way out for developers is to work only with domains/clients they are interested in, but in these days of "distributed agile with optimized resourcing " (english translation == outsourcing half baked projects to the cheapest vendor with over staffed, over managed teams), that is perhaps easier to say than do.

I personally find some domains interesting and find innovation and effectiveness in economics just as fascinating as innovation and effectiveness in programming and, these days, work only on projects that interest me. On the other hand I don't have the security blanket of a 9 to 5 "offshore cheap software 'engineer' " type job. Life is more refreshing this way. :-)

Update:- Bill Caputo makes the "Analysis as a separate activity from programming is meaningless" point (in a slightly different context) brilliantly on his blog.