Rage against unprofessionalism in software engineering
Today software engineers disappointed another person. When I was on a tram 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. Apparently, the game froze or crashed, because suddenly the child turned towards the father saying: “It is not moving, do something!”. Unfortunately, the sentence was followed by “No, I don’t want to start over. Why did it crash?”.
It is the question I ask every time a freshly updated app drains my phone battery at night and I wake up one hour later than I expected. Every time I have to restart my computer because the sound card driver has crashed… 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 pressing buttons it opened the door).
Do you want to show your product/service to 25000 data science enthusiasts every month? I am looking for companies which would like to become a partner of this blog.
Are you interested? Is your employer interested? Here are the details of the offer.
Once I met a random person who after asking 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 relay 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, now we only need to land on the runway.”
- “We have finished the construction work, there are only few missing walls.”
- “The dinner is ready! We are still cooking the soup.”
Unfortunately, I do that too. It happens. Saying that “at least I am aware of that” may be a convenient excuse, but obviously being aware is not enough.
Does the “definition of done” issue show us some 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 arrogance makes us think we can solve every problem by writing software (if you want to look at programmers solving social problems, keep a safe distance because it won’t end up well).
How often do you hear people who claim they do not need to write tests? Some are outraged when you mention TDD. At least in that case I can proudly say that I am a grown-up and I usually write tests. When I don’t, I always regret it later… 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 team work, but firstly 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 serious difficulties with revealing our incompetence. I think the word “privileged” is overused nowadays (and it starts to mean “everyone who has more free time/money/love/job prospects/whatever than I do), but I will write it anyway. In software industry we have a privilege to admit lack of knowledge. Imagine what would happen if you went to a doctor and he or she said “I do not know”. Would you go to that doctor ever again? Honestly, would you? In medicine lack of knowledge is communicated indirectly, by referring a patient to a specialist. We do not need to do that. We are not expected to know everything. The expectation of being omniscient is purely internal. Such expectation may be the only reason forcing us to learn new things and challenging ourselves, therefore we should not try to fight it! It is great when you want to know everything, as long as you remember that it is not possible.
We do not like boring work. I am so guilty of that crime. In my opinion it is the main cause of software complexity. You have a bunch of experienced people and you tell them to write some 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. 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. Quickly we end up with something future employees will call “that f**ing overengineered legacy system”.
Actually, hype driven development is a separate problem which deserves its own article. 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 catalogues? Honestly, I have never heard developers stating 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 think that remains is being new and fashionable. Sometimes it is hard to notice how danger it is. Especially, 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 awesome. Seriously, if you feel the need of overcomplicating your solution even when you work on something extremely simple, choose microservices. They keep the damage, induced by developers trying to make their boring work more interesting, nicely confined.
Do you think that this text will end with an advice, demands or a sermon? No, I am not Uncle Bob. I am just disappointed and ashamed. Tomorrow begins another workweek. The question is, what will I do differently?
Remember to share on social media! If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.