Rage against unprofessionalism in software engineering

Today software engineers disappointed another person. I was on a tram when I saw a father with his daughter, a 5 maybe 6-year old child. The child took the father’s phone and started playing some clone of Flappy Bird. Suddenly, the child turned towards the father, saying: “It is not moving, do something!”. The game froze or crashed. Unfortunately, the sentence was followed by “No, I don’t want to start over. Why did it crash?”.

It is the question I ask whenever I wake up one hour too late because a freshly updated app drains my phone battery at night, or 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 absolutely sure it was not a mechanical problem but some failing software (then after one minute of randomly pressing buttons, it opened the door and let me out).

Once I met a random 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 something is going to be finished 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 wasn’t a problem, we wouldn’t need “definition of done.” Somehow people can’t rely on us even when we say a task has been finished: “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 a 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 ego makes us believe we can solve every problem by writing software.

I think there are two causes or software unreliability: lack of testing and working alone. How often do you hear people who claim they do not need to write tests? Some are outraged when you mention TDD. The other issue is working in solitude. Not literally, there are others in the room, but their existence is ignored.

Have you noticed that when perfection is expected, people always work in teams? Surgeons, firefighters, commercial pilots, etc. Somehow we managed to overlook that. I do not know how to efficiently work in pairs. 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 with revealing our incompetence. In the software industry, we are allowed to admit a lack of knowledge. Imagine what would happen if you went to a doctor and heard: “I do not know.” Would you go to that doctor ever again? Honestly, would you? In medicine, a lack of knowledge is communicated indirectly by referring a patient to a specialist. We do not need to do that because we are not expected to know everything. The expectation of being omniscient is purely internal.

We do not 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 extremely unchallenging and can’t be more boring. Hence they try to find a “better solution.” Sometimes the outcome really is a better solution. The result is often a mix of big data envy, hype-driven development, the “I wish I worked at SpaceX” syndrome, and manifestations of omnipresent Anderson’s Law. Quickly 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 really think that technology radars published by some companies 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 it of all the buzzwords, the only thing that remains is being new and fashionable.

Sometimes it is hard to notice how dangerous it is. It is hard to avoid overengineering when you realize that your problem is, in fact, a CRUD application in disguise, and your big data fits in memory… on a 5-year old mobile phone.

Looking at it from a different perspective, 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.

Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you want to contact me, send me a message on LinkedIn or Twitter.

Bartosz Mikulski
Bartosz Mikulski * data/machine learning engineer * conference speaker * co-founder of Software Craft Poznan & Poznan Scala User Group