We Don't Take Advice From Non-Developers

The Astrophysics of Software

06.01.2026, By Stephan Schwab

When critical decisions about software development are shaped by those who've never written production code, organizations pay a recurring tax: failed projects, departed talent, and developers who learn the new framework vocabulary while joking about it in the parking lot. The most effective organizations ensure that technical decisions are informed by genuine technical expertise.

The Scene That Says It All

There’s a memorable moment in the 1998 film Armageddon where military officials and NASA scientists debate how to stop an asteroid from destroying Earth. A general insists that the president’s scientific advisors believe a nuclear blast could change the asteroid’s trajectory. Dr. Ronald Quincy, a British NASA scientist introduced as “pretty much the smartest man on the planet,” delivers a devastating response:

“I know the president’s chief scientific advisor. We were at MIT together. And in a situation like this, you really don’t want to take the advice of a man who got a C-minus in astrophysics.”

The scene resonates because it captures something we instinctively understand: when facing complex technical challenges, the people who actually understand the domain should drive the approach. A nuclear solution might sound decisive, but without understanding orbital mechanics and physics, it could make things catastrophically worse.

Software organizations face this dynamic constantly. And too often, they choose the equivalent of the nuclear option.

The Conference Room Where Code Goes to Die

Picture a familiar scene: a meeting room where decisions about software architecture are being made. Around the table sit executives, project managers, and perhaps a consultant from a prestigious firm. The developers — the people who will actually build the thing — are either absent, outnumbered, or speaking last.

Someone suggests rewriting the system in a framework they read about in Harvard Business Review. Another proposes blockchain because their golf partner’s company did something with blockchain. A third insists on a vendor solution because the sales presentation was impressive.

The developers exchange glances. They know these approaches will create problems. But they’re outnumbered, outranked, or simply not asked.

Why This Pattern Persists

It would be easy to blame hubris, but the pattern has structural roots.

Hierarchy trumps expertise. Seniority in the org chart confers authority in all domains. The person who excels at finance is assumed to have valid opinions about software architecture. But a brilliant marketing executive doesn’t become a qualified surgeon by moving up the corporate ladder.

Abstraction creates confidence. Software is invisible. You can’t touch it or see its internal structure. This makes it seem simpler than it is. “It’s just code, how hard can it be?” No one looks at a skyscraper and says, “It’s just steel and concrete, how hard can it be?”

Consultants speak the language of power. External consultants succeed by telling executives what they want to hear in strategic-sounding language. The consultant’s confident simplification wins against the developer’s careful qualification.

The Framework That Will Fix Everything

Perhaps no pattern better illustrates the problem than management frameworks imposed on development teams. A new methodology arrives — complete with certifications, consultants, and fresh vocabulary — promising to solve all delivery problems. Developers are sent to training. New rituals are mandated. Dashboards are configured.

And then: nothing changes.

The developers learn the terminology. They attend the required ceremonies. They update work items with expected labels. To executives, everything looks transformed. The organization has “gone Agile” or adopted “SAFe.”

But in the parking lot, a different conversation happens. Developers joke about the theater of it all. They translate their actual work into framework-speak for status meetings, then translate it back to get things done. The framework becomes a productivity tax — overhead to be managed rather than a tool that helps.

This isn’t cynicism. It’s adaptation. When people who understand the work aren’t consulted about organizing the work, the inevitable result is a gap between the official process and the real one. The real process continues in whatever form actually works. The official process becomes performance art.

The tragedy is that many frameworks contain genuinely useful ideas. But imposed from above, without input from those who understand the work, even good ideas become resented mandates.

The Cost of Ignoring Expertise

Organizations that consistently override developer expertise pay a recurring tax:

Projects fail. When technical decisions are made by non-technical people, systems often don’t work as promised. The asteroid isn’t destroyed; it breaks into fragments that cause even more damage.

Good developers leave. Talented practitioners have options. When their expertise is consistently ignored, they find organizations that value what they know.

Technical debt accumulates. The quick solution that seemed reasonable in a conference room becomes a permanent drag on productivity.

Innovation stalls. When developers learn their expertise isn’t valued, they stop offering it. They implement what they’re told, even when they know it won’t work.

What Genuine Expertise Sounds Like

Developers aren’t trying to be difficult when they raise concerns. They’re trying to prevent disasters.

When a developer says “that timeline is unrealistic,” they’re applying years of experience to recognize that certain things take certain amounts of time. When they question a technology choice, they’re considering factors that won’t be visible until months into the project. When they request time for refactoring, they’re identifying necessary work that will be done proactively and cheaply, or reactively and expensively.

The credentials that matter in software aren’t degrees or certifications. They’re having built things that ran in production. Having maintained systems and felt how today’s shortcuts become tomorrow’s emergencies. Having shipped projects that didn’t work out and learned what to avoid.

Creating Space for Technical Judgment

Organizations that build successful software create structures where technical expertise informs technical decisions.

Include developers in decisions. When a choice has technical implications — which means most choices about software — developers should be in the room, not receiving decisions after the fact.

Weight expertise appropriately. When the topic is astrophysics, the astrophysicist’s opinion matters most. When the topic is code architecture, developers’ opinions should carry decisive weight.

Distinguish between what and how. Business leadership appropriately decides what problems to solve. Technical practitioners appropriately decide how to solve them. Confusion between these domains is where dysfunction occurs.

None of this means non-developers have no role. Business expertise, domain knowledge, and strategic vision are essential inputs. But these inputs should inform technical approaches, not dictate them. A CEO might appropriately say, “We need to handle ten times our current traffic.” A CEO should not then say, “Therefore use microservices and Kubernetes” — unless they have the technical background to make that recommendation.

The Question Worth Asking

In Armageddon, the NASA scientists’ approach prevails. The crude nuclear solution gives way to a plan that accounts for actual physics. The mission succeeds because expertise was valued.

Next time you’re in a meeting where software decisions are being made, look around the room. Who’s speaking? Who’s being heard? Are people with relevant expertise shaping the discussion, or being overruled by people whose credentials are in other domains?

If you’re a leader making decisions about software, consider: would you accept a surgery plan designed by your lawyer? A legal strategy devised by your accountant? The technical expertise of software developers deserves the same respect you’d give any other professional domain.

We don’t take advice from the guy who got a C-minus in astrophysics. Perhaps it’s time to extend the same logic to software development.