Once, during the development of a big project, I asked the Product Manager to tell me about the relationship between two functions (let's call them A and B). And the PM said: "When A is not active, B is always disabled". So I've designed my software introducing a strong dependency between A and B.

Then, several weeks later, it comes out that when the functionality C is active, also B must be active, no matter the state of A.

I went to the Product Manager again to have an explanation and he said: "Obviously, when A is not active, B is always disabled except if C is active". So I asked if there was any other exception, and he replied: "No, this is the only one".

Of course he was lying (even if probably not intentionally).

I found two other exceptions during the rest of the development. This led to ugly code and a missed deadline.

Scapegoats?

Who's to blame here? The PM, because he provided me wrong information? Me, because I've forgotten to "trust no one"?

I think both, but not for the reasons I've mentioned. We are both to blame because:

• the PM didn't understand I couldn't know what he considered trivial things, and
• I didn't require him to provide me the whole picture.

Conclusions

When something goes wrong in a big development project, rarely it's due to a technical problem. And it's never a fault of a single part. Most of the time it's a matter of (lack of) communication that involves both sides: who writes the specifications and the developers. We should try to do our best to avoid misunderstandings because we have a common goal: to create a great product.

Cover image by Michael Coghlan taken from Flickr licensed under the Creative Commons Attribution-ShareAlike 2.0 Generic license.