People talks about things they consider important to communicate and not about what they think is implicit. This is normal: life is too short to lose time speaking about things that everybody knows, right?

Unfortunately, in the Developers' World this behavior leads to big mistakes and missed deadlines. Usually things go this way:

  • someone (most of the time the Product Manager) writes the specification and sends it to the Dev Team;
  • the Dev Team asks a million questions about what is written on that specification;
  • the PM answers;
  • the Dev Team do the work and pass it to the Quality Assurance Team;
  • the QA Team, guided by the specifications, tests the product and finds a 2 or 3 (billions) bugs that the Dev Team quickly fixes;
  • the PM looks at the product and screams: "what is this crap?!"

What Has Gone Wrong?

Probably the PM has taken for granted something that for the developers wasn't. I'm not pointing my finger against Product Managers. It's not (only) their fault if their wonderful specifications are focused on few aspects (that they consider fundamental for the product) and everything else is left unsaid.

Another thing that often happens is that the specifications are providing us a solution instead of explaining the problem. So we are forced into railroad tracks that usually are leading us to the wrong place.

And if this happens with people working in the same company and building, try to figure out how the situation can go worst when you have to deal directly with a customer that belongs to a completely different application field.

Saving the Project

How can we solve this? As my boss usually says "we simply don't know what we don't know" (no, I do not work for Monsieur de La Palice), so it seems that we are in a cul-de-sac (to use a French expression).

Something is missing and I don't know what it is

But let's see the whole thing from a different point of view: we know that we don't know (to cite Socrates) so we must ask the PM or the customer to explain not only how he want a certain feature to be implemented, but why he needs it.

We must understand in deep the application field and its critical aspects in order to create a better software that fits the requirements (also the implicit ones). We have to become users, to play the customer's role.

In addition, we should schedule periodic meetings with the PM to check the direction and make sure that misunderstandings are solved as soon as possible. Only following these two suggestions we can avoid situations like the one described above.

Conclusions

It would be wonderful if we could have a document that describes everything is needed (well, sometimes simply having one document would be great) without knowing anything else, right? Unfortunately we live in a real world... or so we think...

Recommended complementary readings: this post by Seth Godin and Estimation is Evil?

Image by Sufined taken from DeviantArt licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license.