Writing a program and shipping software are often used interchangeably. But programming and software engineering are not the same. In this post, I will share my opinions about the problem created by this misuse of the term “software” and the consequences.

Note: The events mentioned in the post are my first-hand experiences.

Software as a livelihood

“Is being good at programming as a hobby a way to succeed in the software industry?” No. The software industry has many variations. The Silicon Valley brand of engineering isn’t global; it is most popular. There are more programmers in the third world, just like English language speakers. Building software has become a source of income for the majority.

Looking back at the early days of Silicon Valley, the place, not the series, one will notice that programming is a hobby trend. However, the availability of infrastructure allowed the ideas to flourish. And once the ecosystem stabilized, the industry thrived into going global via outsourcing. The outsourcing meant instructions from H.Q. to be executed locally. It is similar to Remote Code Execution (RCE)!

In non-technical terms, the execution is often a diluted misinterpretation of the intent. (One can make a movie, “The Good Manager,” with this premise. Since “Lost in translation” is already taken.) The problem, in my opinion, has always been the incentives of the person managing the project. As a result, the project tracking metrics become the dominant factor in every decision. It’s almost bordering on narcissism.

Scrum

“Scrum ही धर्म” seems to be the core objective of software development. So, I will provide an example instead of a rant and leave the rest to you.

In a project, a principal engineer used to read out chapters from the book Clean Code to the junior members of the team every evening. In the same project, there were no unit tests and misused technology. The answer to my rhetorical question to the engineering manager, “What should be our priority unit tests or shipping code?” was shipping code. I decided to quit and did quit within a few months.

War is Peace

The idea of giving teams competing for the same task to maximize output in terms of innovations is a primary factor in attrition. There is no data point capturing this aspect. Wondering why? It’s easy;

People don’t resign from organizations. They resign from the situation.

There is no incentive to speak openly in the exit interview. People often blame managers for attrition, but I think the processes are the root cause. Objectivity is a human invention. It is harder to learn than mathematics. Practicing it is even more complicated. I don’t expect managers to be scholars in stoicism but at least be aware that rivalries become personal.

Developers refuse to upgrade stacks to protect their relevance. As a result, the entire team pays the price for technical debt for the rest of their careers. Please stop waging wars within teams to sound wise in management meetings. The ground reality is not that peaceful. Never forget — people talk outside meetings too.

Freedom is Slavery

Letting developers choose the stack is the easiest way to pile up technical debt. Many developers pick a trending stack to please their next employer. There are three kinds of developers in a company: those who didn’t want to be in the previous company, those who cannot get into their next company, and those who have a big enough EMI to allow thinking beyond appraisals! Of course, this is a crude generalization and shouldn’t extend further. But I hope you get the idea.

Choosing a stack has to be technical, but often, it becomes logistical. I do offer a practice test-based course about it as well. Unfortunately, I am not an expert in selecting programming languages, but no books or guidance are available.

If the project tracking drives the deliverable, there will be no room for disruption. Controlled experimentation is complex. Predicting failures for an undefined or barely defined set of requirements is arduous. Imagine people writing domain-specific languages without even referring back to compiler design fundamentals.

The freedom to choose stack results in slavery to technical debt on most occasions.

Ignorance is strength

Managers have little incentive to do reforms. I bet less than 5% of engineering managers across the globe can spot the correlation between the books High Output Management by Andy Grove, Measure what Matters by John Doerr, and Software Engineering at Google.

I don’t expect managers to have read or even heard about these books. But if they are practicing the OKRs and haven’t bothered about their origins, then the problem is evident. Many feel comfortable tweaking one principle or the other to suit the needs of their team.

The intuition-based policy-making on the fly leads to short-sighted project planning. People start conspiring instead of designing. Indeed trade-offs have to be made to maintain stability and quality, not to please someone in the hierarchy.

Software PTSD

The ship of Theseus brand of engineering leads to stress. At least for me, it has. I like programming as a way to get things done predictably. However, the engineering management I have experienced over the years has differed from the sources the people executing it claimed to have referred.

I appreciate companies having a mental health specialist on board to help employees tackle stress. But that is treating the symptom, not the root cause. The problem with “customer obsession” is that obsession in any form is not healthy and, in some cases, illegal!

Stop PTSD to avoid PTSD.

P.S.: If you are wondering about the origins of the subheadings, they are indeed from George Orwell’s 1984. Please do read it if you haven’t.