See? It Is Easy To Get Off Track
Just when you think you have a firm grasp on the requirements, you may find out you didn't understand them as well as you thought.
Join the DZone community and get the full member experience.Join For Free
One of our vehicles needed some recall work to be completed, so Nicole and I made the drop-off the night before the appointment and left the keys in the specially designed drop-box near the service entrance of the dealership.
The following afternoon, Nicole and I arrived back to the dealership. She went inside to get the receipt for the work and I went over to look at the vehicle parked nearby. When I was about halfway there I heard her say, "The keys are in it."
I kept walking.
A couple of seconds later, I heard Nicole this time ask me, "John, are the keys in it?"
I responded back, "Let me check." I kept walking to the other car, now to see if the keys were left inside.
Seeing me continue to walk away from her, Nicole realized I misunderstood and clarified, "No, are the keys still in the car we drove here?"
Nicole was making sure I didn't end up taking both sets of keys with me, while I was checking to see if the other set of keys were in the same car.
This provided a great example for me on how easy it is to get off track when trying to communicate as a couple.
As one might imagine, when a simple conversation can lead to confusion just how easy it is for confusion to be introduced while trying to meet the acceptance criteria of a set of requirements.
But, It Is An SSN Field
During a recent project, the web developer was required to have a field on the form to house the Social Security Number (SSN). The requirements noted that the format of the field should be XXX-XX-XXXX on the screen, but when submitted only the numeric values would be sent to the Java API for processing.
The developer coded the form as noted in the spec, but became surprised when a ticket was entered into the system. The tester was able to enter alpha characters into the field, which was not valid for an SSN utilized in the United States. Ironically, when the SSN was submitted to the back-end for processing, only the numeric values were sent.
In this case, the developer followed the requirements, but didn't consider the assumption that the XXX-XX-XXXX would be comprised of only numeric values...and maybe the dashes, depending on if a CSS framework was used to auto-show the dashes.
Had this been any field other than a standard SSN, his design would have merit. As an example, if the XXX-XX-XXXX represented an account number and maybe the first three characters would be alpha values. For this particular system, maybe only the last six characters (which would be only numeric) would be sent to the Java API for processing.
While the requirements should have stated the numeric-only requirement, the developer probably should have asked the Product Owner for clarification in order to save a defect from being created.
Design Diagrams Out of Date
While working on a large project, we found ourselves in a position where new developers were being introduced into the project on a faster-than-expected rate. As a result, the ability to make sure every developer was fully brought up to speed wasn't an option. The deadline was approaching and there was a mountain of features to be built.
To assist developers on the project, a mini-application was written to demonstrate the standards and patterns employed by the project. Early on, this helped our entire team understand the UI/UX components we needed to utilize. However, we failed to keep the site fully up to date. Unfortunately, some of the aspects had evolved.
We realized this when the first round of tickets reached the PR stage for the new developers starting the project. They had seen the site in their developer documentation and referenced the site for their work — not realizing the content was out of date.
In this case, time should have been taken to not only make sure the on-boarding documentation was up to date, but that we communicated with each developer before they got started on their own branches of feature work.
It Goes With The Page
On yet another project, I was working with publication terminology. As part of the project, there was functionality to allow sections of the publication to be moved to another segment of the book. Within this industry, there was a proprietary term that referred to a subset of pages that would be inserted into the main book. The printer was able to do this and the inserted pages actually flowed just like the traditionally bound pages of the book. The process was actually quite cool.
When moving pages around, I had asked the subject matter expert (SME) what happens when a page is moved and it includes these subsets of pages. The answer I received was that "the sub-pages stayed with the page."
I took that information and wrote the process so that when a page was moved, any sub-pages would be moved too. So, they stayed with the page being moved. It was quite a bit of effort to make this happen.
When the tester started testing the logic, I received a call. It turns out, the sub-pages need to stay with the page number, not the page itself that is being moved. So, if the sub-pages were on page 527 in the book, they will still be on page 527 when any moves happened.
I had actually programmed the logic backward, which took some time to resolve.
In this case, I should have walked through a full example with the SME to make sure I had a complete understanding.
The Tree Swing Diagram
Years ago, this diagram became popular in the software development industry:
Basically, the cartoon shows how a requirement can be interpreted several different ways. It even has a Wikipedia page.
Like the example at the dealership, Nicole knew what she was asking me and I was answering her, because I knew what she was asking me. However, our thoughts were not the same at all and what I was doing was not at all the expectation she had in mind when she asked her question.
It took a few seconds, but we got back on track.
The biggest way to stay on track is to maintain open communication either through words or even a quick demo or action:
asking the Product Owner for clarification
validate documentation before letting some loose to start development
work through an actual example to minimize confusion
Taking time to check in will certainly save quite a bit of time in the long run. After all, you don't want to be one of those examples in the tire swing diagram, right?
Have a really great day!
Opinions expressed by DZone contributors are their own.