Towards true engineering. Moving software beyond craft to profession.

What engineering actually means

Engineering is the application of science, mathematics, and technology to the construction of useful things. Software clearly has the technology. Where it comes up short is on the science and math — we do not yet have a mature predictive theory of why our systems behave the way they do. In the absence of that theory, we lean on skill and process to compensate. That lean is the signature of a craft, not an engineering discipline.

Guilds, craftsmen, and the transition to a profession

Early mechanical engineering — particularly arms-making — was organized into guilds: craftsmen, apprenticeship as the path to mastery, guild control over who could enter the craft. Swordsmithing is still practiced today, now built on real engineering materials (e.g. 1086 steel) and with no guilds. Software is still in the guild era: entry is gated by informal reputation and apprenticeship; standardized practice varies enormously by shop; and when something goes wrong, the individual practitioner is blamed rather than the process or the profession. That is not how real engineering disciplines hold together under pressure.

• Craft = skill, apprenticeship, guild control, master-craftsman status.
• Engineering = standardized materials, mathematical behavior models, professional accountability.
• Software today is closer to the first than the second.

Empirical engineering, Roman style

The Romans built aqueducts, arenas, and bridges that survive to this day — using essentially empirical civil engineering. They had no Newtonian physics and no calculus. They knew from accumulated experience what shapes worked for what purposes, but they couldn't explain the mathematics underneath. Software is in a similar position: we can build systems that work, but we cannot reliably explain why they work, why they sometimes don't, and what will break when we change them.

Empirical is not enough for the hard problems

You can build an aqueduct with empirical engineering. You cannot build the Seoul subway system — the longest in the world, a marvel of civil-engineering coordination — without true engineering backing the design. The same is true in software. Empirical practice gets you to a functional CRUD app. It does not reliably get you to an autonomous vehicle, a pacemaker, a medical-device ML pipeline, or a power-grid control system without a series of high-consequence failures along the way.

The role of modeling — the Hong Kong bridge

Hong Kong's Tsing Ma Bridge had a specific challenge: typhoons. Stress-testing a completed multi-kilometer bridge is obviously impossible. Engineers built a 1:400 scale replica, placed it in a wind tunnel, and ran Monte Carlo simulations to model storms and failure modes. What made that possible was the combination of engineering materials (steel and concrete with known properties), mathematical models of wind, water, and structural behavior, and ongoing calibration against real-storm data. Software engineering isn't there yet, but we are inching toward it — performance modeling, load simulation, formal methods, AI-system evaluators — each is a piece of the same pattern.

• Materials with known properties.
• Mathematics of the relevant physics.
• Models calibrated against reality.
• Continuous comparison of prediction to outcome.

Engineering materials — the missing piece

Other engineering disciplines build with materials whose properties are published and known: strength, reactivity, melting point, fatigue curve, thermal expansion. Software is built by combining words that get translated into CPU instructions. We don't have software engineering materials yet — standard, tested, reusable components with documented properties. Open-source libraries and cloud services are the start of this, but they mostly publish features, not behavior envelopes. The gap between "functional documentation" and "materials specification" is where many of our worst failures live.

Failure drives standardization

The UK railway-bridge collapses of the 1800s drove standardization — of materials, processes, and certifications. Every mature engineering discipline has a similar inflection point: enough catastrophic failures to force the profession to stop and codify what it knows. Software has started this. CMMI, ISTQB, the various safety-critical standards (DO-178C, IEC 62304, ISO 26262) are real progress. But we still have significant disagreement and inconsistency across the industry. Some worry about premature standardization; others argue that even imperfect standards self-correct faster than no standards at all.

Self-regulation, licensure, certification

In the US, engineers are primarily self-regulated, like doctors and lawyers, with governments enforcing the regulations. Professions with less status — barbers, cosmetologists — are government-regulated directly. The first US engineering-licensure law was enacted in Wyoming in 1907, a century after the profession existed, because "anyone could work as an engineer without proof of competency" was deemed unacceptable for public safety. Software sits where Wyoming 1907 sat. Certification programs (ISTQB, CSTE, various vendor specializations) are the first serious attempts by the profession to demonstrate an ability to self-regulate. They're not the destination. They're the on-ramp.

Not in 150 years? Read the aeronautical history

Naysayers argue software cannot become a real engineering discipline — not even in 150 years. The aeronautical profession begs to differ. The Wright Brothers flew at Kitty Hawk in 1903. Gagarin orbited Earth in 1961. Apollo 9 tested the lunar module in 1969. The Space Shuttle's first orbital flight was 1981. Less than 80 years from first flight to a reusable orbital spacecraft. The analogy isn't perfect, but it makes the shape clear: an engineering discipline's trajectory can be rapid once the materials, math, modeling, and standards come together.

What a true software engineering profession looks like

Six markers. (1) Craft approaches relegated to hobby and personal projects only. (2) Engineering materials as standard, tested, reusable components with known and published behavior envelopes. (3) Mathematics that represents software behavior with useful predictive accuracy. (4) Modeling that's increasingly precise as the math matures. (5) Continuously refined, meaningful standards (not checkbox compliance). (6) Government recognition of reputable certifications — in both software development and software testing. None of these are hypothetical. All of them exist in some form today. The work is to make them the norm instead of the exception.

• Craft relegated to hobby.
• Materials with known properties.
• Mathematics of behavior.
• Modeling that predicts.
• Standards that are real.
• Certifications with teeth.

What any working engineer — and tester — can do now

The profession won't transform from the top. It transforms when individual engineers, testers, and test managers insist on a little more engineering in each program they run. Measure before you standardize. Standardize before you scale. Write the model down. Compare the model to the outcome. Contribute to the standards you use. Earn the certifications that matter. Sponsor apprentices, and graduate them into practitioners who will do the same. None of this requires waiting for a policy change.