The cruelest thing to ever happen in the software industry is the belief that engineers don’t understand and they don’t have to understand the business. I can’t think of another industry in which you can produce without insight into what you’re building.
My favorite unpopular opinion is that no one should have a monopoly on business understanding.
But there is a tendency in the software management culture that tries to abstract engineers from the business as much as possible. There is a belief that engineers should be on the receiving end of the ticket assembly line and each task should be digested and cleared of domain lingo.
I will never understand this tendency.
Not in the managers who think they’re shielding someone from unnecessary information. Not from the engineers who rely on digested tasks that go through multiple layers of product people, analysts and tech leads to get planned.
This is a very dangerous mindset that is holding our industry back.
Most technical problems happen because engineers didn’t understand the business. Purely logical bugs are easily caught in the testing phase. The worst bugs are caused by a misunderstanding of business requirements.
I’ve wasted countless days chasing managers and analysts who are drip-feeding me information about the product I’m building. Much of this time could’ve been saved by building understanding and insight from the start.
Don’t get me wrong, engineers don’t need to know the intricate details of the company’s marketing strategy. Much like marketers don’t need to know about Kubernetes. But the developers need to understand how the product works, what value it provides, and what its pain points are.
That’s one of the reasons early-stage startups move so fast. You don’t have to explain the requirements and hold numerous meetings if people understand the business.
After all, using Kafka sounds great on paper - highly scalable, incredible ecosystem. But will the business ever scale enough to need something more robust than RabbitMQ?
But in large organizations you have control over a small piece of the whole system. Do you have to understand everything? You have to know enough about it to know who can be impacted by your breaking change.
There are very few engineers who want to be grunt coders. Nowadays everyone is looking for meaning in their work, a purpose behind their actions.
The software industry has the insatiable desire to turn into a predictable, assembly line-oriented industry where everything can be measured, predicted, and forecasted. Time and time again, this proves to be impossible.
Programming is closer to writing than science. But we may be able to get at least a bit more predictable if we get a good understanding of the domain we’re building solutions for.
One day someone may share my article and remind me of my foolish thoughts as we all pass tickets down the line, but until then - empower your engineers.
When you have people who only wait for requirements and don’t understand what they’re doing, you end up in messy situations. Technically, the implementation may be correct but practically it doesn’t work.
That’s why you see sign poles in the middle of cycling alleys.
