Keep focus on the problem
Introduction
Hi, my name is Julien, aka chatgris on the internet. I am a lead backend engineer at Zeals hacking on a Ruby on Rails application used by our Communication Designer team.
For once, this post will not be about a particular technical aspect, but much more about what may drive changes in code writing, architecture or even in team workflow and methodology.
The traps
One things I noticed along the time is that some of engineers tends to lost focus of the problem they are trying to solve, and get suck into the implementation. Also, engineers love to try new things, may it be a new language, database, or framework. This is of course an excellent attitude to have in the sense that this mindset helps improving one skills and broaden their understanding of various contexts.
Combine the two, and this can not only lead to various problems in your architecture, but also in your team.
Shiny new thing
Who’s never been tempted to try the “Shiny New Thing” (“S.N.T”)? You know, these brand new and hard-to-miss features, marketed absolutely everywhere thanks to eulogistic articles and blog posts. Exactly like some restaurants become “the place to be”, these features are “the things to try”. However, not so many people ask themselves the real question: why are we using this “S.N.T” ? What is the goal here ? Should we try to implement this “S.N.T” and for what purpose ?
The answer is simple: the goal is not to implement “S.N.T” per se, the goal is to solve a given problem, or even to improve an already existing feature. The same problem can have various sets of solutions and “S.N.T” may just be one of them and not some MacGuffin that will solve magically every one of your problems just because of its sudden popularity.
So, while documenting yourself about “S.N.T” , it is important to also understand why “S.N.T” was introduced in the first place. This miracle feature may work in one context, but may also have a different outcome in a completely different situation. In short, before even thinking of implementing “S.N.T”, a team should first and foremost focus on the comprehension of the problem itself. And by problem, I mean the root cause, not just some consequences. Most of the time, one root cause will yield various problems at differents levels of an architecture, or interface.
From this perspective, I will suggest what is called “The Five Whys”. The Five Whys is an interesting method to find the root cause of a problem. I really recommend you to take a minute to check it out, even if this method should be handled with care because asking yourself “why” too many times can eventually become a problem in itself. The idea is to look for the disease, not the symptoms. Sometimes, the disease will be to complex to treat, but, you will learn more about the root cause. And sometimes, treating the disease will make things so much simpler.
Go back and re-assess
Once you master “The Five Whys”, evaluating if “S.N.T” can solve the problem at hand will get easier and easier. From my experience, the most common pitfall I witnessed is to lose sight of the problem and be sucked into an endless tunnel that makes even more complex the reach of a solution. Once this basic and yet useful understanding is acquired, and with a bit of experience, you’ll then be able to evaluate if “S.N.T” may be a viable solution.
Just remember that during implementing and re-assess, you should always go back to the original obstacle and ask yourself if “S.N.T” is still a good tool in your context. Sometimes while implementing “S.N.T” (that will still look fresh and awesome when using it), you’ll start to realize it will require way more changes than you initially thought. For engineers, it is quite common to get excited in this part of the process and invest more time and effort than necessary. However, this mindset may solve the initial issues, but down the road, it can also create a complete new sets of complications like for instance tensions inside your team because of new unexpected changes, introduce new cost in your cloud billing or just become a plain maintenance nightmare.
Just keep in mind it is never a failure to recognize that, all things considered “S.N.T” did not work as well as you originally expected and that you should look for another way. Why? Because in the process, you learned more about the problem you faced, and you can start looking for another solution with a better understanding of said problem, but also about “S.N.T” itself that may be helpful in the future, in another context.
