Common Mistakes of Performance Metrics — With Lines Of Code
Let me start this with an exciting story. A few years ago, I was having dinner with a bunch of graduates who were joining the organization. During the usual chitchat, someone raised a topic about performance. So I asked whether you measure you are the best performer in your university. Without any hesitation, they mentioned —
I can write 2000 lines of code per day.
And the discussion went on and on. One was quoting 3000, and someone even 10000. It blew my mind immediately.
This clearly shows our education around self-performance. Like how schools look for marks and your performance is being measured by how many extra sheets you have taken during your exam, this diluted thought process not only creates harm around education but also in the so-called niche software development industry.
More is better
As a developer, you spend more time reading the codebase than writing. Today excellent SaaS products have been built using collective open source solutions. Movies and fake articles already portrayed software development negatively, where coders are becoming typists and aiming for the highest word per second count.
I don’t think any developer even writes 100 lines of code per day. What happens when you aim for more lines of code as metrics to impress yourself and your teams?
You deliver bloated software. Since we have CI & CD to deploy that soft, it. It leads to increased ship time since it will take more time to compile and build. That means you are boosting it to a higher cost of change. In addition, that bulky software needs to run on some cloud server which may require frequent deployment, leading to higher latency, and primarily for developers who are going to develop on top of those unreadable codes, it now requires more time to maintain. That results in a higher maintenance cost.
Less is better
On the flip side of the above point, I came across many gigs who find reducing lines in art. Yes, it is an art, but like any other art which takes time to understand and relate to, your code also becomes like that.
Let’s take an example of a function having the if-else condition and some computing. Sometimes, having a separate external function of a one-time small computation might be overkill, but it must have a genuine reason. But for the sake of reducing lines, like a challenge, I will write it in one line, and adding it to production code will not only make the life of your fellow developer messy but also it will create cryptic code that no one can read. It will never achieve success but more bugs in your product that now take more time to resolve.
In an ideal world, we must aim for the business problem if you were asked to go from your home to your office, which is 10km from your home. You would not take a flight, travel to Hawaii and return, board a bus or train, and reach your office. Neither will you jump walls to aim for a straight line to achieve the distance. You will take the best possible path to your destination safely and effectively. The same goes for code; you must solve business problems with the most efficient code. Efficiency comes from different product-related performance metrics, not by lines of code.
Hi all,
I am starting a thread on common mistakes of performance metrics here. Often some of us measure our performances based on so-called famous metrics (in a different way), leading to ambiguity and drops in team/application’s overall performance. The idea of this series is to educate you on a few common misconceptions that we must avoid.
