The Problem You Solve Is More Important Than The Code You Write ?

50 years ago, in 1968, there was the Working Conference on Software Engineering, sponsored by the NATO Science Committee. At that time, people started to notice software was becoming a fundamental part of society. However, it was also becoming too hard to understand. After that conference, programming started to become a whole industry. It started to move away from the control of business people.

Regardless of the path programming has taken since then, there’s still a problem with the separation between business and software development — or «engineering» as the conference called for the first time. If developers become too narrowly focused on development, they can miss the purpose behind the software they write. They may not see hidden solutions that don’t require any code.

Here’s an example.

There was a startup building a device to allow a person to unlock the door of their house using Bluetooth. The visual interface to communicate with the device was a widget, visible even when the phone was locked. It had a single button called “Open the door.”

When the user came closer to the house, they would grab the phone, find the widget, and then click the button to open.

Somebody looked at that workflow and asked:

If we’re using Bluetooth and assuming whoever has the phone can enter the house, why do we need to make somebody grab the phone and push a button? Let’s allow the door to unlock when it detects the device approach by 1 meter. This way we don’t need to pay the cost to design and code a visual interface!

The Bluetooth story is an excellent example of narrow focus: The goal was to unlock the door with minimum effort. It makes no sense to design a visual interface if the sensors are wireless.

If you’re aware of what the business is trying to achieve and what’s the value to the user, you can merge that knowledge with your knowledge of what’s possible with the technology. Only then you’ll have enough information to come up with better answers and conclude an interface is not necessary for a product.

That is an excellent example of how to solve a programming problem without having to write any additional code. However, just like Technical Debt, nothing should be used as an excuse to write crap code in the rest.

Not every code is worth writing

Sometimes, the fix for a severe bug may not be a priority. If you’re a crypto exchange and your system allowed a duplicate deposit to happen once, human intervention can be the best cost-benefit solution if the cost to fix the problem is high.

This trade-off between Severity and Priority reminds me of a model a colleague showed me recently. It’s called The Priority Matrix, a bi-dimensional model that can be used to prioritize bugs based on how many users it affects and the severity.

The single duplicate deposit issue described earlier falls into the category of inconvenience that affects one user. Therefore, priority 3.

Not every bug is worth fixing

It’s very common as developers to try to write scripts for everything. However, some repeatable tasks may not be worth automating. You don’t need to spend the time to code scripts if you’re going to hide essential knowledge of how the underlying command works.

There’s a difference between encapsulation of complex logic and abstraction of useful knowledge. Sometimes, information should be explicit to be comprehensible. If you abstract them, they can have the opposite effect and be harder to understand.

It’s more useful to use some types of low-level commands in the CLI than a high-level command that abstracts knowledge, such as Git aliases.

Not every command is worth scripting

Years ago I worked on a project using Incremental Delivery. It was an identity verification system that would ask for the user to submit some personal data to be verified by a third-party provider.

There was this fancy field validation feature the team wanted to build. However, the validation story was being de-prioritized on every sprint planning as the deadline became closer and closer. In the end, the team figured out that it didn’t make any sense for the fancy validation to exist in the first place.

Here’s why: The verification was mandatory!

It was in the user’s interest to provide valid information. If the user provided wrong data, they wouldn’t be validated and wouldn’t be able to use the system. Besides, most browsers supported a standard HTML validation that was good enough.

In the worse case scenario, users that couldn’t verify themselves would call support to be verified manually.

Not every feature is worth coding

As a developer, if you understand the problem you’re trying to solve, you’ll be capable of coming up with better code, and sometimes no code at all. You are not a Code Monkey paid to write characters on a screen. You’re a professional paid to solve problems.

However, if you try to solve every problem with the technology without some thinking, as if the code is a Silver Bullet, you’ll have trouble to understand what gives value to the customer and be able to come up with great ideas.

Your purpose and the purpose of the code you write is to generate value and make the existing world a better place, not to satisfy your egocentric view of what the world should be.

There’s that saying: “If all you have is a hammer, everything looks like a nail.”

It’s better to have a nail first so that you can consider the need for a hammer.

That is, if you need a nail in the first place.