I was recently copied on an email thread where some requirements were discussed between a project lead (Bob) and the client (Fred).
(FYI – the names are made up)
Bob asked Fred about a specific requirement that read (paraphrased):
The Error Indicator should display every 60 seconds.
My next task was to add this indicator (the error condition has already been implemented). I looked at how I was going to add in this indicator, and I quickly found out that in order to satisfy the requirement, as written, that I would be going against-the-grain of what was already in place.
That’s fine, we are always learning more as we go, right? Well, I have a very limited amount of time to get this new build out, so I can’t just go re-writing all of the existing logic (it’s been tested and released already, and I’m not sure I can get it done in time). Well, I can achieve this by adding in some 1-off state machines and manage state for just this indicator.
But there was another option. The current implementation didn’t cater to a 60 second period…instead it was a little more frequent, and event based.
I asked Bob if he would talk to Fred about the intent of the above requirement.
When Bob asked Fred if displaying the above mentioned Error Indicator more frequently was okay, the response was awesome (paraphrased):
I don’t see any problems with the proposal. Not quite sure why it is easier than “every 60 seconds”…I thought it would be harder.
Great! Now I can work with-the-grain, and I don’t have to go create a bunch of complicated, 1-off state machines, just for an indicator that only gets displayed in a rare error condition.
Keep in mind…
- we are on the same team, shooting for the same goal
- many times our clients don’t fully understand our software, and don’t always know what is easy or hard
- the client is, generally, willing to work with us to make certain that we are satisfying the intent of the requirements, versus prescribing what exactly must happen
So remember…you won’t know, if you never ask!
