The business comes first

Published on - Updated on

This article is an opinion. I‘m sharing this opinion to provoke a discussion and put my thoughts on paper. As my views evolve, I will return to this article with updates.

On this website’s About page, I mention that it is crucial that “the business comes first”. In this article, I wanted to take a couple of minutes to explain my thought process and add some nuance to this statement.

First, let’s clarify what I consider to be the meaning of this phrase:

I do not mean that technical considerations should be thrown out of the window to meet unreasonable business deadlines. In most cases, this will cause delays further down the road due to the accrued technical debt.

Understanding the business domain

Too often, when a new feature is being developed, I see a mismatch between what a product owner wants and what software developers understand them to need.

The software developers don’t understand the business domain or context properly, so they can’t ask proper questions.

The product owner tries to explain things in technical terms, leading the software developers to implement the software in a certain way.

Eric Evans understood this challenge and described this in his famous blue book as the need for a shared “ubiquitous” language between developers and the business.

There are two essential questions to ask yourself for any new feature development:

Understanding the feature’s goal will allow you to indicate, to the business, whether or not you are still on track for achieving said goal.

Understanding the terminology used by the business will allow you to write code that uses the business’ language and will prevent confusion in the long term.

Dealing with technology hype

Every couple of years, there is hype concerning some new technology that has become available for software developers. The internet is ablaze with opinions about that technology, and all companies seem to be starting a migration track to move to the new technology.

Even though the new technology being hyped might be innovative, and a step forward, we should apply some healthy skepticism whenever the hype wave starts. In many cases, the technology might not apply to your business size, the size of your user base, or your specific subject area. I’ve often seen people suggesting a NoSQL database for a feature that is easier to implement with a standard relational database.

New technologies solve specific problems. Understand which issues this technology solves and which ones it does not. In most cases, the added complexity and need for training that comes with new technology is not worth it.

Use the technology that solves your problem in the most straightforward and maintainable fashion, and unless you’re working for a big company, avoid betting on too many different technologies. If you don’t, you might get dragged down by the waves.

Knowledge sharing

There are two essential reasons for sharing a company’s technical knowledge in a written-down fashion:

Here are some types of knowledge that are useful to share as separate documents:

There are definitely more than these, but those have helped me a lot in the past.

Other knowledge should be documented closer to where it is needed:

There are also techniques for reducing the knowledge that needs to be shared:

There is much more to be said about this topic, and I would love to hear it if you have any feedback or suggestions.

References