Anders Hovmøller

 /  2 min read

The toughest stakeholder I ever had wasn't a person

Building pharmaceutical software under FDA 21 CFR Part 11 - and what the industry's hardest constraint taught me.

Illustration of the first page of the FDA's final rule on electronic records and electronic signatures, 21 CFR Part 11, as printed in the Federal Register on 20 March 1997
Illustration based on the first page of 21 CFR Part 11, Federal Register, 20 March 1997.

It was a regulation.

Long before electric propulsion and connected boats, I spent years building software for the pharmaceutical industry.

Compliance-critical systems: adverse event reporting for clinical trials, pharmacovigilance and audit systems. Software where a bug wasn’t just a bug - it could become a patient safety issue.

That meant FDA 21 CFR Part 11.

And Part 11 didn’t care how elegant my code was.

Every requirement had to be traceable. Every change assessed, tested, approved and documented. Access control, audit trails and data integrity weren’t features - they were fundamental. The system had to remain in a validated state throughout its entire lifecycle, not just pass a test once.

At times, it felt like overkill. Writing validation protocols and documentation when I wanted to be building new features.

Some of it was.

Documentation nobody has really thought about isn’t quality - it’s noise. The difference between good and bad compliance isn’t the amount of paperwork. It’s whether someone actually made a conscious decision.

But the core principles changed how I build software. Permanently.

Twenty-five years later, I find it fascinating that traceable changes, audit logs, controlled deployments and protected data integrity have become standard practice across the software industry - just under different names.

Pharma got there first.

Not because the engineers were smarter.

Because the consequences were greater.

Sometimes the most frustrating constraint in the room is the one teaching you the most.