Developer given Mission:Impossible – fixing rubbish code that could crash a city – simply chose not to accept it
An On Call reader for The Register, nicknamed "Socrates," recounted an early career episode as a fresh-faced software manager sent to a power station to document an undocumented monitoring system. Confronted with poorly written, uncommented control code for a turbine overspeed detector, he judged the risk of accidentally causing a catastrophic failure too great and chose to walk away rather than attempt a fix, leaving the system untouched.
Socrates found the code riddled with random GOTO statements, arbitrary memory address accesses, and unexplained bitwise operations, with no comments to clarify its purpose. Fearing that a mistake could trigger a turbine overspeed event, potential equipment damage, or even a wider blackout, he decided the safest course was to back away from the keyboard entirely and leave the system as it was, a decision he now regards as a valuable early lesson in professional judgement.
- Engineer sent to fix undocumented power station monitoring code
- Found the code dangerously messy, with no comments
- Chose to leave it untouched rather than risk a turbine failure
New here? Start with this
Power stations use monitoring and control systems to track equipment such as turbines, which generate electricity. An overspeed detector is designed to identify when a turbine is turning too fast, since excessive speed can damage machinery and disrupt power generation.
Older systems may contain software that is hard to understand, especially when it lacks comments explaining how it works. Changing control code without knowing its purpose can introduce faults, so engineers may need to assess the risks and seek specialist knowledge before attempting repairs.
Both sides, in good faith
The strongest fair case each way — we don't pick a winner.
The case for
The developer exercised prudent professional judgment by recognising that the risks of inadvertently breaking a poorly understood safety-critical system outweighed any benefits of attempting repairs, and that when code is functioning despite poor quality, the safest course is to leave it untouched rather than risk introducing catastrophic failures through well-intentioned but potentially misguided modifications. This reflects valuable wisdom: sometimes the most responsible action is to acknowledge the limits of one's knowledge and avoid intervening in dangerous territory without proper expertise and safeguards.
The case against
Whilst avoiding reckless modification was sensible, simply walking away from demonstrably dangerous code left a significant hazard unaddressed in critical infrastructure, and the appropriate professional response was to escalate the issue forcefully through management channels, commission expert review, and ensure proper remediation rather than treat inaction as equivalent to safety. Leaving such code untouched indefinitely does not solve the problem; it merely defers the inevitable crisis and abdicates the responsibility to raise alarms about known hazards affecting public safety.