Fitness metaphor for Software
I have been coding for over two decades, and have been a fitness enthusiast for a few years now. Developing and maintaining one’s body and that of developing software are both human endeavours and have similar misconceptions, constraints, principles, challenges and gotchas.
I present the metaphor of fitness in an attempt to bring focus on key aspects of software development. It would be icing on the cake if it motivates the readers to work on their health.
Awareness and self-deception.
Before I started my fitness journey I held an opinion that I was fit for my age and minor adjustments to my lifestyle would suffice to lead a healthy life. I think this line of thinking is shared with a large segment of people. I accidentally stumbled upon a fitness program that was an eye-opener and, I have been working hard for years now, and I still have a long way to go before I attain desirable health and fitness levels.
“My code is good” is a mindset held by a large segment of developers. They usually focus on a small subset of characteristics, they are either unaware or apathetic to others. More often than not, code can be smaller, more readable, can be developed faster, can support more features, and can provide more business agility. Some of the attributes of good code are mentioned here.
“out there” mindset.
Nutritional and dietary supplements exist for helping with health and fitness, but they don’t suffice. One needs to supplement with exercise and lifestyle changes to work towards better health.
Similarly, for software, tools exist for modelling, deployment, persistence, integration, etc., but developers still have to perform a lot of work. Discretion needs to be employed, and learning, experimentation, and analysis must be performed. Developing good software requires good engineers, and a lot needs to be done for an engineer to be good. A good list of thinking patterns required is mentioned here.
Misleading metrics
Body Mass Index is a metric used to assess the fitness of individuals
In the picture below, there are two avatars, with similar BMI.
The avatar on the left is stronger, leaner, and healthier than the one on the right. He would be able to lift heavier weights, run faster, have fewer ailments, and live longer. Similarly, two pieces of code can perform the same functionality and have varying degrees of understandability, ease of change, scalability, and life. As demonstrated in the avatars, BMI alone can be a misleading metric and has to be analyzed along with other metrics to determine health, similarly, functionality(what) has to be combined with other metrics (how) to determine the quality of software.
Brute force approach.
Let’s consider the right avatar, let’s assume that he is a determined individual. How would he fare in a long-distance run? In spite of his best efforts, he is likely to struggle in it, he might injure himself or do other bodily harm. He would have to lose weight and build muscle and stamina to run long distances.
Working with badly written code is similar, one can wrestle with it and make it do more for a while, but sooner rather than later it will become hard, if not impossible for it to do more. Like the left avatar will outperform a determined right avatar, a developer who has access to better code will outperform the one who doesn’t. Code has to be refactored/rewritten to be useful when stretched.
Quick results.
Getting a fit and healthy body has been a multiple-year journey for me. Sustaining isn’t a given either. Magic diets and quick-fix regimes don’t work, the initial results don’t sustain. One needs to watch what and when they eat (and drink), how much they sleep, how much they exercise, degree of stress.
Working with badly written software isn’t any easier. It takes lots of patience, discipline and rigor to fix its flaws.
Need for sustained effort
If one works in a gym for a few days a week and is a glutton for the other days. It is highly unlikely that he/she would lose weight. Losing excess weight can only be achieved through calorie deficit over a prolonged duration.
Maintaining the quality of code isn’t different. As long as the system is being used, its entropy will increase, this will increase software rot. Continuous and opportunistic refactoring and other measures need to be performed. If one were to inherit a badly written code, the entropy has to be continuously reduced similar to calorie deficit for weight loss.
Structured process.
To gain and maintain fitness one needs to follow a structured regime, one has to gradually increase intensity, duration and weights. Proper diet has to be followed, right techniques have to be followed.
A similar structure is needed to develop meaningful software. Coding practices, design methods, and tools need to be scrutinized, reviews done, continuous integration and deployment need to be automated, and so on.
Well begun, half done.
It is much easier for people who are fit to remain fit than those who are unfit to gain fitness. The same is valid for software, code that starts good can be kept good more easily, rather than making the code suitable retroactively.
