The Highly Effective Ways a Software Engineer can Choose Languages, Tools, and Frameworks.
Some days back in office I heard a Software Engineer curse the C# Language. He used the 4 letter word in anger. I didn’t know which part of C# pissed him off. But watching him get frustrated tickled my curiosity. I wondered if it would have made him happier had he had a say in the selection of the Language.
I have been in similar frustrations before. I felt I was a victim of someone else bad decisions. Every day was a battleground. No company will ever spend money to software just to make a programmer happy. If it’s in production, then it’s a done deal.
So the question to ask is as a Software Engineer should we have a say in deciding which Language, Tool or Framework (L-T-F) are appropriate for a project. And most importantly, how to make the right choice. Java or C#, Kafka or RabbitMQ, AWS or Azure; how do we make sure our choice is correct. And it doesn’t come back to bite us in the future.
In my experience, Time, Cost, and Effort are the three fundamental factors to keep in mind while deciding. However new, popular or beneficial is the L-T-F, if it doesn’t fit into Time, Cost, and Effort criteria you are wasting yourself. Being Software Engineers we are always tempted to use the newest of Language-Tool-Framework. However, additional factors like Familiarity, Support, and Documentation need to be weighed too.
Below is the explanation on each of these factors.
Time:
How much time we possess determines if we pick a Familiar L-T-F. Limited time requires faster results, meaning more mastery is required. Also, quick support and rich documentation can compensate for the lack of time. Unfamiliarity has a longer learning trajectory.
Cost:
How critical a Software is for the business determines how much it is willing to budget for it. Higher budgets are assigned to projects that require time and attention of lots of highly skilled people. Performance, Life of the Software play a role in determining how complex a system is and how much deep expertise it requires.
In the absence of necessary skilled workforce, companies buy out Systems instead of custom building them. If budget allows your team to buy instead of build, then you can save yourself some trouble of learning new L-T-F. A deeper analysis of the time required to build versus buying out existing tools will assist compare the costs. This will help understand who will support and maintain.
Effort:
The effort is the measure of the skill required to solve a problem. It accounts for how much action you have to perform with an L-T-F to get a job done. In the absence of knowledge and skills, then the effort is required to ramp-up. Effort directly impacts how much time it takes. Therefore also increasing the cost. In situations where the timeline is tight, it makes more sense to pick L-T-F that has the least effort.
Familiarity:
Productivity is directly related to Familiarity. Experience brings speed, and wisdom that gives momentum. When we pick an L-T-F that we are familiar with, more time is spent on doing rather than learning.
Restriction:
Restrictions like Security make a difference in final decisions. Recently, a project was scrapped because the security team did not approve of it. They found a security vulnerability which needed the app to be completely re-written.
Unlearn to Learn:
How can we benefit the Object-Oriented features of C++ if we continue to write linear code like in C language. As we gain experience, we tend to become biased. To learn new L-T-F, we should unlearn first. Solving problems with new L-T-F is to be done natively to maximize the benefits.
Open Mind:
Asking around us is important as a Software Engineer. Don’t limit your research to just the internet. By asking around, you are essentially checking if what the Internet says applies well for your ecosystem. Also, keep an open mind while researching. If we try to use research to validate our choice leads to no better outcome. Since your mind is already fixed not the choice, it becomes hard to recognize important points.
Conclusion:
As Software Engineers, we have to come up with solutions with the best use of intellect. However, it takes practice to make better choices. Don’t beat up yourself if your choice seems bad. Remember that given the situation you were in and the constraint you have; you did your best to solve a problem. Just keep the learning going.
__
Comment below what you keep in mind when deciding which Languages, Tools, and Frameworks as part of Software Engineering job.
