Rage against unprofessionalism in software engineering

Today software engineers disappointed another person. I was on a tram when I saw a father with his 6-year old daughter. The child was playing a clone of Floppy Bird on the father’s phone. Suddenly, she turned towards the father, saying: “It isn’t moving! Do something!”. The game froze or crashed. Unfortunately, her next words were, “No, I don’t want to start over. Why did it crash?”.

“Why did it crash?” is the question I ask whenever I wake up one hour late because an updated app drains my phone battery at night, and the alarm clock doesn’t ring. I ask that question when I have to restart my computer because the sound card driver stopped working. Even that one day, when I got stuck in an elevator. Despite knowing nothing about elevators, I was sure it was a software failure, not a mechanical problem (then, after one minute of randomly pressing buttons, it opened the door and let me out).

Once I met a person who, after asking me what I do for a living, said that he is a project manager and he hates programmers because they are liars: “They always tell you that they will finish on time and they are always late.” At that time, I was shocked and annoyed. However, right now, I think he may be right.

We have a problem with finishing things. If it weren’t a problem, we wouldn’t need a “definition of done.” Somehow people can’t rely on us even when we say we have finished a task: “It is done, but…”. Could you imagine similar situations in different professions?

“Ladies and gentlemen, we have reached our destination, but now we must land on the runway.”
“We have finished the construction work, there are only few missing walls.”
“We are still cooking the soup, but the dinner is ready!”

Does the “definition of done” issue show us also different problems? Maybe the root cause is our arrogance? We often think we know everything, can foresee the problems, and mitigate them. Egoless programmers are mythical beasts, just like unicorns. Our egos make us believe we can solve every problem by writing software.

I think there are two causes of software unreliability: lack of testing and working alone. How often do you hear people who claim they don’t need to write tests? Some are outraged when you mention TDD. The other issue is working in solitude. Not literally, there are other people in the room, but we don’t cooperate with them.

People work in teams when we expect perfection. Have you noticed that? Surgeons, firefighters, commercial pilots, etc. Somehow we managed to overlook that. I don’t know how to work in pairs efficiently. Because of that, I tend to avoid pair programming. I feel that learning it may be a real game-changer for me.

Maybe we all can benefit from proper teamwork, but first, we need to overcome our biases, habits, and doubts. Do we need to protect our egos and pride by avoiding other points of view? Worst of all, we have severe difficulties revealing our incompetence. In the software industry, we are allowed to admit a lack of knowledge. The expectation of being omniscient is purely internal.

We don’t like monotonous work. In my opinion, it is the leading cause of software complexity. You have a bunch of experienced people, and you tell them to write another CRUD. What will they do? Their job is unchallenging and can’t be more boring. Hence they try to find a “better solution.” Sometimes the outcome is a better solution. Often, the result is a mix of big data envy, hype-driven development, the “I wish I worked at SpaceX” syndrome, and manifestations of omnipresent Anderson’s Law. We end up with something future employees will call “that f**ing overengineered legacy system.”

The worst part of hype-driven development is that we start using new, cool technologies and techniques without understanding them deeply. According to Robert Smallshire (https://www.youtube.com/watch?v=3cjSpH4SYpU) it is like the fashion industry. We like things only because they are new. Do we think that technology radars are fashion catalogs?

I have never heard developers saying that “Java and Spring Framework are so last season. This year all cool kids write microservices in Scala, but we think that Elixir will be popular in the Summer 2017”. However when you listen to the conversations and strip them of all the buzzwords, the only thing remaining is being new and fashionable.

Sometimes, we can’t notice how dangerous it is. We won’t avoid overengineering when we don’t see that our problems are, in fact, CRUD applications in disguise, and our big data fits in memory… on a 5-year old mobile phone.

Because of that, the idea of microservices is fantastic. Seriously, I love microservices, but probably for the wrong reason. I think that they are perfect to confine the damage induced by bored developers. If the team likes to overcomplicate their code, tell them to build a microservice. In the worse case, you have only one application to replace with something done better.

Rage against unprofessionalism in software engineering

A year of Poznan Scala User Group

Related Posts

Query string validation in Fastify

Assert object pattern

Turning greenfield projects into brownfields projects