In a precedent post, I was describing how being the user allows makers making good relevant software. This is actually possible because in that process users and makers will interact until they reach the actual problem they want to solve together, removing all sorts of misunderstanding. If you don’t work closely you’ll end up having makers and users not having the same vision of the problem, with awkward misunderstandings in the resulting solution. Or a product which does much more than what’s needed (which is much worse than what we intuitively tend to think). A lot of arguments occur between developers on the degree of genericity the code should reach. The argument generally looks like “- They told us the requirements was that, so we should do that, not more. - Yes but users don’t know a thing about software and our other clients, we should generalize as much as we can.” Generalizing is the right thing to do in that context, because when you can’t interact with the user to know where the requirement comes from, you’ll make the safest assumptions. And the result is that the problem being solved ends up much larger than the one which actually needs to be solved. And this is extremelly costly. There is another behaviour in the development team, we generalize what’s cheap to generalize. And we don’t have the budget to generalize what’s expensive to generalize anyway, as it won’t be part of any requirement, which means it’s not in the budget. It is not possible to generalize everything. Or it is called creating Excel again.
Knowing the exact problem to solve will end up saving a tremendous amount of time for everybody. It sounds obvious and it is obvious, but still project organisations are not optimised for that. Organisations tend to be optimised to protect sides against each others. There is little space for empathy. But empathy is mandatory to reach productivity for both sides, going in the right direction for everybody.
Matthieu Scholler 18 March 2013