In my last blog, I discussed how different activities in product development may give rise to quite contrary attitudes.
For example, capturing requirements seems to be inconvenient for many developers because maybe they don’t know how to interview stakeholders and how to document their needs.
It can be striking to see how some of the same developers get into exaltation when switching over to software coding.
Now they get creative, they can experiment for hours to get things right, and their anxiety seems blown away.
One can wonder why the same developers react in such different ways?
And are developers generally better to write code than to capture requirements?
I claim that this is not the primary explanation. I have seen happy developers writing lousy code.And I have seen anxious developers writing excellent requirements.
The difference is that the developers believe that they are better at writing code than requirements. And why so?
I firmly believe this is a question of support.
If you master a programming language, you think you have all the support you need. Period!
Without worrying, you write unreadable code, impossible for others to review, and contain many errors. (One can wonder how this behavior has become the industrial norm?)
A developer documenting requirements has no language to turn to and no thick manuals to contact when in doubt.
It is also much more challenging to write requirements than code. All this sends an uncertain feeling to the developer.
The simple conclusion is as usual – get a CPDM book. It will work in two contrary ways.
1) The developer capturing requirements will understand the complex nature of requirements.
2) The developer writing code will realize that detailed language support is far from enough.
In both cases above, both developers (or the same one) will be much better product developers.