This blog posts aims to provide an answer to the following question: 'But WHY does it takes you 2 weeks to implement this basic button?' 😆

As a software developer for 10 years, I've heard this question multiple times, and I guess if you too are a developer then you'll also hear it. This question is actually a cry for help, the request from someone trying to understand how something that looks simple in his opinion requires multiple days or weeks of a skilled developer to implement. This person is confused by the mismatch between the feature 'simplicity' and the time needed to deliver it.

Let's take the example of SonaPlay, a new company making computer games. Today, the company is actually 3 people, 3 friends who love computer games and decided to start a software company to pursue their passion. They create their very first game: Times of Heroes, a multiplayer RTS game that happens in medieval times. Right now, the game allows players to fight each other with multiple units: soldiers, archers, knights and catapults. It's still an early phase in the game development so game mechanics are limited.

I would like to explain software complexity by comparing two usecases: adding a new player unit now, or later when other features have been added.

Usecase 1

For this usecase we're willing to add a new unit to the game: spies. Spies are special units able to 'convince' enemy units to switch from one player to another player. But this only applies to 'human' units: soldiers, archers, knights. Catapults cannot be convinced to switch sides.

At this point in the game, units can simply move and attack so adding the new spy unit is not an expensive addition to the game. As mentioned before, only catapults are exceptions to the 'convince' capability of spies. Implementing the 'spy' unit in the game can be translated to:

• add a new unit with 120 health points
• similarly to other units, this unit can move in any direction but cannot attack
• this new unit has a 'convince' ability with a cooldown of 60 seconds
• 'convince' can be targeted against enemy soldiers, archers and knights
• spies cannot 'convince' each other

So this is a fairly simple feature and, looking at the description, we can guess this should not take long to implement for our 3 gamer friends.

Usecase 2

In this second usecase, let's say the spy idea has been postponed. The game then evolves and so does the company. The team grows which allow to ship more complex features.

The game now features horse archers, boats, swordsmen, axemen, elephants, ballista. Boats and elephants can 'carry' other units. Units can not only move and attack, but also defend, jump, eat, be healed at a hospital and teach other units to upgrade them. Units still have a health bar but also a stamina bar and a hunger bar. Players can also construct buildings. Additionally units behave differently whether they are alone or in a group, near a friendly building or near an enemy building. The game has become more complex (and hopefully funnier to play).

We're willing to add the new spy unit to the game at this moment. The description of this new feature has become longer as the game is more complex. Adding a new unit inside that complex system requires more thinking. Let's see what it means:

• add a new unit with 120 health points, 50 stamina points and 20 hunger points, unable to attack other units
• similarly to other units, this unit can move in any direction, but also jump, eat, be healed and teach other spies
• this new unit has a 'convince' ability with a cooldown of 60 seconds
• 'convince' can be targeted against enemy soldiers, archers, knights, swordsmen, axemen, elephants (but NOT ballista, catapults, boats, buildings)
• spies cannot 'convince' each other
• a group of spy does not behave differently than a spy alone

As you can see the description of the behavior is now longer and needs to answer more situations. Not only do we need to implement the new unit behavior but we might also need to update the behavior of already implemented units.

Consequently we can expect that the time to implement usecase 2 will be longer than usecase 1.
And this is only about the rules! Remember that any character on screen needs to be animated. In usecase 1, only 'move', 'convince' and 'die' animations were needed but now additional animations 'teach', 'heal', 'eat' and 'jump' need to be drawn. Let's not forget the game has sound so more audio need to be recorded. Animations and sound are also more expensive to create in usecase 2 compared to usecase 1.

Real-life example: translation

A popular example of this problem is translation. Let's say you have a e-commerce website which can be browsed in English today.

Usecase 1: adding a new button. Fairly simple: choose location, design it, implement its action, choose the English text to be displayed on top of it.

What if the e-commerce website starts to sell in multiple countries, and to do so new languages need to be supported? The website can now be browsed in English, Spanish, Greek and Moroccan. It means that any text displayed on the website must now support 4 versions, and visitors can choose which version they want to read.

Usecase 2: adding a new button. The button must still be designed and the action implemented, but now 4 texts must be defined instead of 1, one for each supported language. Also the same sentence / phrase in one language can be longer or shorter when translated to another language, so the button must accommodate multiple text lengths. Same feature, longer to deliver. And as the number of supported languages grow, so does the cost of adding new tests to the website.

Conclusion

As you can see, the very same feature implemented in two different existing systems, one simpler and one more complex, takes more time to be implemented. This is the cost of systems complexity: adding a new feature or behavior in a already complex system can be very expensive even though the feature itself is simple. The cost lies in making it work with the whole existing system, making it fit what is already built.

EDIT on 2023-02-22: I found a tweet that highlights the above statement: jesseddy/status/1627923011490975746