I work on medical devices that improve and save lives but the work actually kind of sucks. You spend most of your time on documentation and develop with outdated tools. It’s important work but I would much prefer “move fast and break things”. So much more interesting.
Personally, you couldn't pay me enough to do the latter and I'd be more than happy to do the former (but I'm not exactly looking for a job).
I suspect you may have just been unlucky with where you ended up. I'm getting closer to retirement myself but I no longer have to work for 'the man' so in that sense I got really lucky. But I really sympathize with how you feel. So, count the days, and look forward to something nicer. Best!
So it is definitely possible. But it isn't common, that's definitely true.
On the other hand, it sounds like the company you mentioned is worth imitating where possible. They sound awesome. Are you allowed to name them? Is there any writeup on how they balanced velocity and regukatory approval?
Unfortunately not. But the devices they make are absolute life savers and I found it one of the most interesting jobs I did in the last couple of years because I think I learned more from them than they learned from me. I was just focusing on a handful of details, they had to keep the broader picture in mind all the time and educate me to the point that my knowledge became useful to them.
You are probably right that they are uncommon, but the fact that the company was led by a scientist who was very much involved in the process and the mission and offloaded as much of the non-essentials of the CEO job to others made me feel I had gone back in time to be near HP when they were just founded. In the longer term I expect them to dominate the space.
Other times it's just because there are lots of other teams involved in validation, architecture, requirements and document management and for everyone except the developers, changing anything about your process is extra work for no benefit.
At one time I worked on a project with two compiler suites, two build systems, two source control systems and two CI systems all operating in parallel. In each case there was "officially approved safe system" and the "system we can actually get something done with".
We eventually got rid of the duplicate source control, but only because the central IT who hosted it declared it EOL and thus the non-development were forced, kicking and screaming to accept the the system the developers had been using unofficially for years.
I find the risk here that the requirements are the average of all requirements, so the exceptional things don't really get highlighted.
Because you now get this giant amount of text shoved in your face, you switch from thinking to validating. Is what's there correct, vs starting from a blank canvas. The doc already curtails your thoughts.
Kinda like all cars are starting to look the same. No one takes risks anymore.
No-one wants to / feels empowered to / has the knowledge to ask the really difficult questions.
I often wonder if we have created the correct balance here. How many quality of life years have been lost due to the decades lost by being conservative? And how much of the conservative pace is done for the “right” reasons vs personal or corporate CYA?
For safety regulators, the incentives are all on the side of limiting acute downside (e.g. a plane crashing), not maximizing potential aggregate upside (e.g. millions of tons of fuel saved per year and millions of tons of C02 not in the atmosphere).
Society punishes regulators that approve products that kill people, so regulators adapt to this and as a result tend to be very conservative.
Regulators don't capture any of the upside (reputational or otherwise) when a new product enters the market and cures disease, makes cars more efficient, helps planes land on their own in an emergency, etc.
I don't know what "right" should be here, but you've hit on a good point. It's complicated.
(please don't)
I suspect a lot of aviation is the same.
Many private planes use outdated tech, carbeurated piston powered engines driving propellers.
Maintenance heavy, but all of it is well known and stable.
High integrity computing is full of pain staking processes, exactly because no one trusts C developers to do the right thing.