[Off-Topic] Estimates Are Promises. Promises Must Be Kept.

Browsing Quora, I found a simple but interesting question: “Software Engineering: What is the hardest thing for a software engineer”. It’s a subject I’ve been reflecting on for many years. I answered there in English, and it’s worth republishing a Portuguese version here too.

I’m a software engineer and, after twenty years across different companies, markets, and teams, I see a pattern. Practically every engineer I’ve met starts with the premise that “code” is the goal and the solution to every problem.

The truth is that, in the market at large, software problems aren’t solved with software. I’m not talking about the exceptional cases of research and development or academia. This is the first and hardest thing every engineer struggles to understand, and fights against.

Linda Vasquez: I know he made you a promise, but circumstances have changed.

Francis Underwood: The nature of promises, Linda, is that they remain immune to changing circumstances.

– House of Cards

One thing a lot of people cite as the hardest is “estimating,” because you so rarely land on the right estimate. And that’s where the problem lives: the phrase itself is confusing.

Estimates, by definition, will never be “correct.” If they were, we’d call them “predictions,” and they’re two separate words for exactly that reason. In a prediction the variables are known and fixed, the path is predictable and automatic. That’s the lab scenario: “given ideal conditions of temperature and pressure, in a vacuum, with zero friction, a toy car at a constant speed of 10 meters per second, for 10 seconds, travels 100 meters.” And estimates?

Outside the lab, we have estimates, and estimates are PROMISES.

Promises are made to be kept. A promise doesn’t resolve itself. You have to make a deliberate effort to reach it and keep your word. With estimates it’s the same: you estimate and then you work hard to deliver what you promised.

“But the manager/client/investor/boss keeps pressuring me to add more things, make changes all the time, breaking my concentration with irrelevant problems all day long.”

Yes, they do this, and they’ll keep doing it, yesterday, today, and always. The most common reaction is to get defensive. To avoid committing, people decide to give no estimate at all, or throw out a number so out of proportion that any “extra” is sure to fit. That’s a terrible default.

Say you promise your daughter you’ll be at her school presentation. You blow it and show up two hours after the whole thing is over. That failure is yours, and yours alone.

It wasn’t traffic, it wasn’t the surprise meetings, it wasn’t the weather. You made the promise and didn’t prepare for the bumps along the road: leaving earlier, getting ahead of the problems, building in slack for the unexpected. You left everything for the last hour, walked out at the last minute, and, of course, shit happens.

With estimates it’s the same. You said a number with no commitment, no sense of responsibility, and did nothing to get there beyond sitting down and writing code. You never went digging to explain the problems.

Saying it once, your way, doesn’t mean the other end understood. Whoever starts the communication is responsible for finding a way to get the message across; without that, communication didn’t happen. To communicate is to be understood, and being understood is the responsibility of the person talking.

So you failed at communicating, at managing your own time, at helping your peers with the problems. All of it was your responsibility. Writing code was the smallest part.

Having a sense of responsibility is exactly the second hardest thing every engineer faces. If the starting premise is that they only answer for “writing code,” they don’t see the broken communication as their own failure. So they rarely own the outcome: it’s much easier to blame everything else. And that comes straight from the first difficulty, the wrong premise that your only goal in life is to write code and that every problem is solved with code.

This doesn’t apply to software alone. It applies to the musician, the cook, the builder. As a working professional, sure, you’re expected to be great at your craft. But that’s the bare minimum of the foundation, and there’s nothing exceptional about being technically good, however impressive the skill may look.

There’s no point writing the most elegant, perfect code if it solves the wrong problem. It’s like composing the most perfect Beethoven-style classical piece for a job that called for music at a kids’ birthday party. So one of two things: either you don’t take the kids’ party, or you write the best pop tune you can. If you took it and stayed, either you deliver with exceptional quality, within expectations, or you own the fact that you can’t and step aside, without getting in the way of whoever can solve what you couldn’t.

Anyone offering a service needs to understand one thing: the goal is to implement the best possible solution, but for the right set of problems. And the hardest part is finding that right set. Clients come to professionals precisely because they don’t know either. It’s on us to help find those problems, to judge whether keeping the promise is within our reach, and then to keep it, managing every obstacle that shows up along the way.

It sounds simple put like this, but even experienced engineers fail to grasp this truth, and plenty get away with breaking promises using tricks to hide the hole they dug.

So learn the first and hardest truth in the world: software is normally not solved with software, it’s solved with human capabilities. On a Pareto distribution, I’d say 80% of every software problem only gets solved when you invest the remaining 20% in communication, articulation, clear and rational thinking, breaking ambiguities, negotiation, and commitment.

Given all that, it can look easier to never promise anything. Except that never promising means never committing, and never committing means never being a professional. That’s exactly what separates the amateur or hobbyist from the professional: making promises and working to keep them. It also happens that you don’t hold up your side because it depended on the client, the boss, or whoever holding up their side first. A mutual exchange of promises is the whole reason there’s a referee called Justice, and the instrument that records those two promises has a name: a contract.

All that said, can you keep every promise? No, unfortunately you can’t. But it’s our responsibility as professionals to always chase that ideal, instead of inventing ways to dodge it.

I’ve said more about what I consider a professional to be in a 2011 post, "[Off-Topic] Opinions, Truths, Democracy, and Ethics".