IT for Adults

“Ship fast, fail fast”, sometimes shortened to “fail cheap”, is a common mantra in agile environments.¹ It addresses real problems with rigid processes, hierarchies, and tech stacks. For years, the industry has promised higher speed through agile methods. That sounds good. Still, when people ask if I work in an agile way, I avoid a straight answer.

People confuse speed with maturity. Moving faster does not fix a wrong direction. Speed as replacement for clarity.

I am old school about this. I do not bookmark good articles. I save them as PDFs with wkhtmltopdf and keep them locally.² I have done that for years. One of those files is much older: Charles Fishman’s “They Write the Right Stuff” from 1996. It used to be free online.³ Now it sits behind a paywall.⁴

His description of great software and how it kept the space shuttle running feels out of place today.⁵ No rapid application development.⁶ No minimum viable product.⁷ No trial and error as a management principle.⁸

Slow to build, fast and stable to run

Great software takes time. Teams do not experiment until something works. They define requirements before writing any code. This is standard systems thinking, not an opinion.⁹

About one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do – and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change.

Agile iteration assumes the problem is already understood.¹⁰ In practice, that assumption often gets ignored. Sometimes on purpose. In environments where failure is expensive, final, or irreversible, moving targets, missing null checks, or weak error handling can cause total failure. When serious assets or even lives are at stake, there is no second chance.

Change still matters. It just has a cost. Changes must be documented, explained, follow a defined process, and be tested. Agile approaches often rely on judgment in the moment and individual decisions. A slower approach relies on processes and standard operating procedures to reduce risk.¹¹ Only what can be verified and reproduced is trusted. Documentation and version control are not just collaboration tools.¹² They are control systems.

Testing as structured competition

Testing is another key factor. Developers and testers are two sides of the same coin. Long before anyone talked about gamification,¹³ NASA set up a system where both sides worked against each other in a controlled way:

The central group breaks down into two key teams: the coders - the people who sit and write code – and the verifiers – the people who try to find flaws in the code. (…) They’re in competition for who’s going to find the errors. Sometimes they fight like cats and dogs. (…) The result is a friendly adversarial relationship.

That idea feels uncomfortable to many teams today. There is a strong preference for harmony among developers, project managers, and executives.¹⁴ It also clashes with the spirit of the Agile Manifesto.¹⁵ Current AI narratives go even further and claim both roles can be automated. Fortune recently called that what it is: corporate fiction.¹⁶

Mindset matters

Slow developers and testers do not fit common success stories. Their work does not show up well in simple metrics like lines of code or time to resolve issues.¹⁷¹⁸

Importantly, the group avoids blaming people for errors. The process assumes blame - and it’s the process that is analyzed to discover why and how an error got through. (…) The way the process works, it not only finds errors in the software. The process finds errors in the process.

Fishman describes an organization with a high level of maturity. They build software for adults. It is sustainable, reproducible, and safe.

That’s the culture: the on-board shuttle group produces grown-up software, and the way they do it is by being grown-ups. It may not be sexy, it may not be a coding ego-trip – but it is the future of software. When you’re ready to take the next step – when you have to write perfect software instead of software that’s just good enough – then it’s time to grow up.

It is a myth that software and IT systems always need constant fixes, monthly hotfixes, and heroics during incidents. Most systems work as specified. They are reliable, fault tolerant, and stable, with minimal downtime, as I described in “How to Measure IT Success”.¹⁹

Not rocket science

A common objection is that this sounds like rocket science. People call it overengineering or theory without real world value. They argue that companies cannot afford this level of discipline and that requirements change too often. They also claim NASA had the luxury of time.

That misses the point. This is not theoretical. It happens in everyday companies. Core data and key processes often stay the same for decades. What is truly mission critical is often underestimated, especially where IT is tightly integrated into production.

Launching a working ERP system, often heavily customized or built from scratch, is just as critical for a mid sized company as a shuttle launch is for NASA.

Support for this approach already exists in the form of standards and audits, as long as they are actually followed and not treated as a checkbox.

Fishman addresses these objections clearly. He separates tools from methods. The methods, the basics, are neither complex nor expensive. It is a mindset. It is engineering discipline. And it is exactly what software development has lost:

The most important things the shuttle group does – carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code – are not expensive. The process isn’t even rocket science. Its standard practice in almost every engineering discipline except software engineering.

I have seen too many executives dismiss maturity as bureaucracy. That is the real problem. Good software and successful IT projects do not happen by accident. They come from discipline, clarity, and solid engineering.

In that context, the Slow Code Manifesto is worth reading.²⁰

Best regards,
Tomas Jakobs