“Seems” and “Should” — The Enemies of Good Software Development
A story
Somewhere in a galaxy far, far away there exists a world where everything is ruled by logic and every question that needs a yes or no answer is answered with either a “yes” or “no”. (In binary terms a 1 or a 0:)
There is no gray area or in-between state and the answer can be depended on logically to move on to the next question as in a flow chart:
However, what happens when there is not a clear answer of Yes or No, 1 or 0? Then the next step can’t reliably be determined. Welcome to a world closer to ours. The world of “Seems” and “Should”. In this world these words are frequently used when there isn’t certainty on the part of the person answering the question. E.g.,
Dev1: “Was the new feature deployed to production today?”
Dev2: “The deploy seems to have succeeded”,
Dev1:“uh, ok. Is it working properly”
Dev2:“It should be.”
In this essay I’ll explain why the usage of certain imprecise words during software development are detrimental to maintainability, reliability, and delivery. Imprecise words such as these probably not good in most contexts either because they lack certainty when certainty is a requirement:
Dev1:: “Is the baby in her crib?”
Dev2:: “She seems to be.
Dev1:“Uh, ok. Then is she sleeping on her back?”
Dev2:“She should be.”
Who knows what the outcome would be if the answers to those questions are No?
In software development we have a similar need for certainty in all cases and it is important for us as devs to hold ourselves and our peers to high standards to ensure that we produce and maintain good, well-written, bug-free code that can be relied upon. Also, it feels satisfying to say that your code is deployed to prod and working as expected. It frees developers up individually, and more importantly, collectively to move on to the next thing. Phrases like “seems to be working” should be excised from the vernacular and should be eradicated. While these kinds of phrases look like harmless exercises in caution they are actually detrimental to the overall confidence the team, and by extension the organization, has in the quality of the code.
What can we do?
Let’s look at each word and talk about practical and pragmatic substitutions.
“Seems” — Any time you catch yourself saying that something seems to be done/working/deployed/bug free/completed/merged then you need to stop and verify your statement before responding. This takes effort and a willingness to venture into the unknown, especially if you need to use an unfamiliar tool or process or to speak with a colleague to verify your results. I guarantee that when you practice this verification you will feel more confident in your statement and go to the mat defending it:
Mgr: “Was the feature deployed to production today?”
Dev: “You’re damn right it was deployed! The End-To-End tests passed at 10:51AM and the package was deployed at 11:03AM. The manifest version was bumped up to 1.0.4 and contains our feature. I ran post-deployment smoke tests to ensure that nothing was broken and verified the feature using a test account. Also, we set up this DataDog monitor to alert us if something catastrophic happens.”
Mic drop.
“Should” — Similar to “seems” this word should be removed from our daily lexicon as much as possible. It is equally bereft of precision. We need (I almost said should) to decide what we want to do, take a deep breath and plan it out. This may take time, patience, and similar to the fix for “seems”. You may need to employ unfamiliar tools or procedures and may need to (gasp) talk to colleagues to really know what to do. Once you’ve developed this plan you’ll feel great and your team will breathe a sigh of relief at not having to worry about X, Y or Z for a while (that is until you decide to execute the plan.)
So, in conclusion try to avoid using “seems” and “should” in our chosen field of software development or on any field — soccer or example:
Mgr: “Did Man U score a goal to break a 1–1 tie in the 89th minute”
Dev: “Seems like it.”
Homework:
Go to your Slack and search for “seems” or “should” and see how many results you get. Write down that number and go play the lottery. Good luck.
