Roger Almeida

A blog about tech

The hard thing about software engineering

Most programming languages are very simple languages. They have a limited number of reserved words that the software engineer will use to describe and represent the software. Check this:

Language # reserved words
Java 67
Python 33
Ruby 41
Golang 25

If you think about programming as learning a new language, the language itself would be much simpler than English, Portuguese, Korean or any other language used in the multiple countries around the globe. And there are millions of people who can speak these languages. It is actually not uncommon to find people who can speak multiple languages.

The tool used to create the source code behind the softwares we love are also languages. Programming languages. And these languages are much easier than a spoken language like German, or Portuguese for instance.

The programming languages have their “grammar” rules (lexical rules to be clear) but they are much easier than all the rules (and exceptions 😩) that exist on any spoken language.

On modern programming languages the compilers and linters are very good at telling you if your code is correct or not. The modern IDEs (Integrated Development Environments) and text editors also give realtime feedback about the code syntax. So typing code in an programming language is not the hard part. Anyone can do it with minimal training.

If that is the case, what is the hard part of creating software?

⚒️ The hard thing about programming

One of the most respect authors of Software Engineering books says there are two hard things in software development:

I actually have two other items that I believe are part of the hard things:

🤔 Know what to do

I know that if you are not a software developer you might be thinking:

Roger, that cannot be that hard.

Trust me, most of a software engineer time will be spend just understanding what needs to be done. Different from physical products where people know the limitations of our universe and what is possible and what is currently impossible a software based product exists only as an idea. And the software engineer needs to figure out what is the idea that the user has on its mind. This is hard ‼️ Before the Agile revolution in early 2000, software development projects would spend months just gathering requirements. People would make a living as a System Analyst which job was to write technincal documentation so that Software Developer could understand what to do. Luckily, we were able to learn from our mistakes and with the Agile revolution, we moved towards an iterative development process where instead of “gathering requirements” we would understand an small part of the “whole idea”, capture it as User Stories, develop quickly and do a demo to receive feedback about the implementation of the idea.

🎻 Compose a song for the 25th year weeding anniversary

Let me see if I can apply that to a non software project.

Suppose you are a musician, and I ask you to compose a song for my upcoming 25 years wedding anniversary

I can tell you that I would like a valsa, and I would like it to highlight special moments of my marriage that I’m more than happy to tell you. The wedding anniversary is in 7 days.

You could:

Clearly the option number 3 is the one with higher chances of producing the best outcome. Doesn’t matter how much I try to document my musical taste, I would never ever be able to tell you exactly the kind of music I can hear in my brain. If you send me drafts as early as possible that would be the best way for me to provide you feedback on the notes, phrases, wording, key, BPM, length, dancing/non dancing, etc…

Agile methods apply the same principle for software: The sooner we show “someone” what we are thinking the better

🙆🏾‍♂️ Know how to do it

This one is hard to explain to non-technical managers but I’ll do my best. Lets pick a concrete example. Assume we are developing a website to find and buy the best flight from one city to another. And we have an user story in the following format:

As an user
I want to pay my flight using my Credit Card
So that I can book my flight for my next travel

It sound very straight forward from a business requirement point of view, but the technical solution behind it can be enormous. Some of the questions that a software developer will have to think about are:

That not to mention the actual drawing of the technical solution. Deciding where in the code each behaviour will be is an huge task.

🐢 The easy trap

An extra point is this perception for the people that are not doing the work that it is easy. In my experience everytime someone starts a planning session by saying “this is simple” or “it is easy” I assume that either the person doesn’t know what she/he is talking about or it is a trap.

Sometimes both are true.

Software development is a constant trade off between now and the future. I 100% agree that there is an easy way to solve an specific requirement. But doesn’t come for free. Giving enough time and you will come across a situation where the development velocity of a technical is so slow that the team will start to claim that they must rewrite the software. Software is like your car, you must spend time and cash with maintenance if you expect to extend its lifetime.

👩‍👩‍👧‍👧 Enterprise software engineering is a team play

Besides all the technical decisions involved into building software, there is also the people aspect of it. In my experience business who optimise for the the people aspect win in the long term. More and more business are adopting policies like:

And as Mayers Briggs has observed decades ago, sometimes two people cannot work well together while the same 2 people on different scenarios are high performers.

So another hard part of the Software Engineering is to define and support the team forming, storming, norming and performing phases and its transitions.

And because it is a team play, it doesn’t make any sense to try to measure an individual performance in isolation. This would only undermine the team ability to evolve as a team.

04 Sep 2023