How Developers Can Satisfy Requirements And Hand-over Quality Code
As a software developer, below are two of your most critical responsibilities:
- Correctly interpret provided requirements (perhaps with some provided implementation details) into a concrete implementation
- Hand-over quality code to QA
If you fail at either of these, your co-workers, managers, and stakeholders will likely be dissappointed.
For example, you might correctly interpret requirements. But, if you hand-over poor quality code to QA you’ve failed.
QA is meant to be a last-line-of-defense, not the only line of defense!
You might say to yourself, we’ll of course, I’ll just write unit tests.
But, think about this question, how can you write good unit tests if you’ve incorrectly interpreted requirements?
Unit tests are no better than your interpretation of requirements.
Alternatively…
Your code can be of impeccable quality, but if your implementation misses key requirements, under-implements requirements, or incorrectly interprets requirements you’ve failed again
Now, at this point you might say, “It’s not my fault! The requirements are always bad!”
Unfortunately, in the real world, this excuse doesn’t fly.
Why not?
Requirements are insufficient so often, that your ability to deal with insufficient requirements is a key factor that distinguishes great developers from average and below average
Saying “requirements are bad” is a valid statement, but the real question for you as the developer is: “What process will you use to get the information you need to clarify requirements before your start your feature AND DURING your implementation!”
On this point regarding process, the three common mistakes I’ve seen average and below average developers make are:
Mistake #1: The developer puts insufficient effort into understanding the requirements
He scans the requirements for 30 seconds, and off he goes to write code.
Invariably he’s failed to think through the requirements sufficiently and thus has written deficient code and deficient test cases.
Mistake #2: The developer believes he can avoid human interaction during development because he believes requirements are and should be 100% accurate
This developer retreats into his cave to write code with plans to triumphantly emerge in spring like a bear leaving hibernation.
In reality…
100% requirements accuracy is a fantasy
Regular communication with all key stakeholders is ALWAYS critical to PATH correct during implementation.
For example, many agile methodologies encourage regular demos for this very reason.
Remember: Deficiencies in requirements and specifications can often ONLY by found DURING implementation.
There is nothing like DOING something to discover problems.
For example, if you’ve ever worked on a car (say, changing your brakes) or tried to do your own home remodel, you’d be surprised how often you have to go back to the hardware store to ask questions, buy new tools, etc.
This is because, despite knowing exactly what you are trying to accomplish — and perhaps reading up on it, until you start a job you cannot anticipate everything you might encounter.
This is true during development, and it’s also true for those who wrote the requirements.
Requirement insufficiency is simply a reality of life; in fact you can count on it!
So what is your responsibility?
A great developer realizes that this is why no set of theoretically “perfect” requirements can ever replace regular, timely communication.
Mistake #3: The developer plows through despite knowing requirements are lacking
In the real world, you MUST be productive despite some unknowns.
If you’re waiting for perfect requirements before getting started you will never get work done.
However, when you encounter questions that can have a material impact on the success of your feature, you MUST take the responsibility to ask questions of the stakeholders who requested, wrote, and edited the original requirements and specifications.
If some of your feature’s stakeholders are hard to reach, you MUST find a suitable proxy
A proxy is someone knows enough about the feature to accurately answer questions on behalf of a key stakeholder.
For example, if the stakeholder for your feature is the CEO of your company, you may have difficulty getting time on her schedule.
But that CEO should have designated a proxy who can answer questions in his place.
If, for an important question, you do not have access to the needed stakeholder(s), NOR A PROXY, you MUST document this and escalate.
Don’t just plow forward.
Plowing forward without answers from a stakeholder or proxy can be disastrous
Going back to working on a car, or a home remodel, let’s illustrate why plowing forward can be disastrous.
Imagine you’re changing the brakes on your car, and you find a strange part in the box and you’re not sure where it goes. You check the manual, and the manual isn’t clear.
Should you simply guess and attach the part wherever you feel is sensible?
Plowing through could cause a life-threatening catastrophe!
Likewise, with development.
If the requirements aren’t clear, and you plow forward with your best guess, you’re inviting catastrophe at worse and frustration among key stakeholders at best!
You can save yourself and other a lot of pain by pausing development to ask questions.
Mistake #4: Failure to add your own technical requirements!
Typically, especially if your team is using an Agile model, there are technical requirements that are overlooked during the planning process.
For example, session timeouts for 3rd party APIs, bandwidth limitations, etc.
Before and during implementation, document technical requirements as you discover them!
And like above, if a technical requirement conflicts with a non-technical requirement, communicate!
Finally, a word on how to use the above to improve your code quality
After you’ve done the above to understand your requirements, you’re now in a much better place to write thorough test cases.
Most developers try hard to test their code before handing it over to QA. Hopefully that includes you!
But, if you fail to thoroughly understand your requirements — including unstated technical requirements, no amount of testing on your part will be sufficient.
Conclusion
Your first responsibility as a developer is to deliver features that satisfy stakeholder requirements — according to THEIR interpretation of what they wrote, not yours.
Your second responsibility is to deliver those features with high quality.
But, in my experience, poor quality code often stems from a developer failing to think sufficiently deep regarding requirements — including unstated technical requirements!
To deliver better features and code quality, you must FIRST make a greater effort to understand and document requirements both before and DURING implementation.
If you do this, your stakeholder(s), co-workers, and manager(s) will be more satisfied with you implementation! In addition, you are also more likely to write better unit tests and to do better manual testing, which will improve your code quality!
Doing these things will help you stand out as a GREAT, rather than average, developer.
