In my work, I often see developers implementing solutions without getting the
full picture first. This is a problem because it often leads to patches
instead of proper solutions. Patches make the code harder to maintain because
instead of having a solid foundation, bits and pieces are held together with
band-aids.
The analogy
Let’s use the analogy of bicycles on paths.
There are
bicycles coming from three different paths, and they all pass the same check
point before continuing on their routes.
The paths represent the
code flow, and the bicycles represent the scenarios that could happen.
The task
Imagine that this is your existing project. You are tasked with ensuring
that if a bicycle comes from Italy, they need to have an Italian flag on them
before passing the check point.
The way an inexperienced developer
would approach this task is to only focus on the path from Italy. Since
bicycles on that path do not have an Italian flag on them, they slap on an
Italian flag before the bicycles pass the check point, at point D. So this
scenario is fixed, and they declare that their work is done.
Here
some of you might say, who would do that? It’s obvious you need to add the
flag at point C. If you were thinking that, congratulations, you are right!
But remember that this is an analogy, and these paths are not so clearly
visible when you are looking at code.
How to paint a full picture
As mentioned earlier, an inexperienced developer would just study the
path from Italy and look for a place to place their sticker. But what if this
inexperienced developer were a little more careful, and asked themselves
whether this is the correct place to place that sticker? How would they
determine which is the correct place along that path from C to D?
This
is where they could ask themselves a couple of questions:
1. Is there
anyone else going through this point besides bicycles from Italy?
2. Are
there any other ways bicycles could come from Italy, without going through
this point?
The first question ensures that they do not mistakenly
add stickers to bicycles coming from other places.
The second ensures
that they do not miss out adding stickers to any bicycles coming from
Italy.
By looking for the answers to these two questions, they will
actually be able to draw out the paths (i.e. code flow) above to better
visualize the scenario, and then this drawing would help them say, “It’s
obvious the sticker should be added here!”
This is why getting a
full picture of the existing system is a must when working on a task. This
step is crucial to finding a correct solution.
What if…?
About the questions that a developer may ask themselves, there is also a
third question that some more discerning engineers may think of:
3. Will
all bicycles going through this point, eventually go through the check point
where we need the sticker?
To know whether this question is
relevant, there is another question that needs to be answered first: What if
the sticker is added to bicycles from Italy that do not go through the check
point? The sticker may not be necessary, but would the presence of the sticker
be a problem? The answer may vary for each scenario. (Example 1: If we need to
hold a valid passport to cross the border to exit the country, is it okay if
we hold a valid passport but do not exit the country? Example 2: If we need to
wear a heavy winter jacket when taking a flight to a cold country, is it okay
if we wear the heavy winter jacket although our flight is cancelled and we are
staying in Malaysia? You decide…)
What do you think?
Do you apply this technique as a developer? What other techniques do you use to ensure that you are implementing a proper solution?
If you haven't tried this method before, give it a try in your next task; it might help you more than you think.
Thanks for reading!
