Hi, my name is Julien, aka chatgris on teh internet. I am a backend engineer at Zeals hacking on a Ruby on Rails application used by our UX Writer 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.
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.
And 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 blogposts. Exactly like some restaurants become “the place to be”, these features are “the things to try”. However, nobody asks themselves the real questions: why using “S.N.T” ? What is the goal here ? Should we try to implement “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 McGuffin 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. 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. But I’m digressing.
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. Sometimes while implementing “S.N.T” (that will still looks 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.
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.