I think it would be pretty cool to have had some IoT on my keyboard for all the code I have written to tell me how many lines I have written over the years.
But I would love to cross-reference that statistic with how much code I have rewritten based on poor requirements.
How much code I deleted?
How much code I had to update?
How much time was loss?
I generally try to keep to code on this blog but at the core of every great release are the requirements that are built at the beginning, middle and end. Do a bad job on those and I can guarantee what the end result will be.
When jumping onto a new project or product, the first thing I always do is sit down with the user and the person writing the requirements so I can see how close they are to understanding each other’s visions for what the end product will be.
If they are closely aligned, I know we’ll be in good shape, if they are far apart, I know I have to plan for some additional work on my side to bring them closer together.
As much as developers would like to ignore this part of the process, they can’t. Well-written requirements are the first step in a successful software delivery.
The developer’s role might not be to write the requirements, but their role is definitely to ensure that everyone has a complete and thorough understanding of the problem everyone is trying to solve as well as ensuring that the requirements stay true to that focus.
I published a Presentation on SlideShare a few years ago on How to Write Great Requirements, the content is as relevant today as it was then.