It Depends

That's the answer I would always get from the lead developer on my team, many years ago. I wanted clear, concise answers from someone with experience, yet he never said "Yes" or "No." It was always "It depends."

Isn't it better to upgrade MySQL to the latest version? "It depends."

Isn't it better to upgrade our Ubuntu version to the one that was just released? "It depends."

Our PHP instance is reaching end-of-life, isn't it better to upgrade it right away? "It depends."

At the time, that felt like the wrong answer. The correct answer was obviously "Yes." Of course it's better to do all those things. But there was so much that I couldn't see yet.

---

Have you considered that the main application using this instance can't be easily updated? It doesn't support newer MySQL drivers, which means we'd have to go through the process of upgrading the application first before touching the database. So yes, upgrading is better in theory. But it depends on whether we can allocate the time to do it in the right order.

It's great to move to the latest version of Ubuntu, but our policy was to stay on LTS releases for stability. Yes, a newer version means new features, but it also means risking breaking changes in a production environment. When you're responsible for systems other people depend on, latest isn't always safest.

At the time I asked this question, we were running PHP 4.x. PHP 5 was already out and receiving patches. Yes, upgrading would have improved performance and closed critical vulnerabilities. But we also ran several forums that had never been tested on PHP 5. In hindsight, they were completely incompatible. A hasty upgrade would have taken them offline.

My lead developer had been doing this for years longer than me. He'd already watched systems break after rushed upgrades. He'd seen obvious improvements cause cascading failures nobody anticipated. When he said "it depends," he wasn't being evasive. He knew there was a list of variables I didn't even know to ask about yet. I heard a non-answer. He was actually giving me the most honest answer possible.

The more I've worked as a software engineer, the less I give black-and-white answers, and the more I understand why.

When a product team asks if it's possible to build a feature, the answer is never a simple yes or no. It depends on the timeline. It depends on what else we're working on. It depends on team bandwidth, technical debt, third-party dependencies, and a dozen other factors that aren't visible from the outside.

My friends who are learning to program often ask me: "What's the best programming language?" I'm always tempted to just say "machine code" and leave it at that. But the real answer is that "best" is meaningless without context. Best for what? Best for whom? I could say Python, but what if they're building an iOS app? I could say JavaScript, but what if they're writing data pipelines? The question assumes a universal answer exists. It doesn't.

A doctor doesn't say "exercise is always good" without asking about your heart condition. A lawyer doesn't say "you should sue" without reviewing the facts of the case. A structural engineer doesn't say "that wall can come down" without checking whether it's load-bearing. Expertise in any field means learning which questions to ask before answering. And understanding how much the answer can shift depending on the variables.

The more you learn and specialize, the more you see the variables that others miss. And the more you see those variables, the harder it becomes to answer a simple question simply. Because you know it's never actually simple.

---