[vjvjvjvjghv]

“ Imagine getting to go to work everyday to work on something that actually saves lives.”

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.

[OptionOfT]

Well, I'm glad it's that slow. I can't shake the idea of the horrors it would be to get a glucose pump whose software has been vibe-coded.

[AlotOfReading]

I work on team managing safety critical code. Management has asked to increase our AI usage, especially for generating requirements.

[vjvjvjvjghv]

That’s not necessarily a bad thing. I often encounter badly written or conflicting requirements. An AI may be better at detecting problems or gaps than humans.

[OptionOfT]

Yes and... no.

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.

[phil21]

I certainly get it. But I also am very frustrated with the snails-pace development of closed loop glucose pump system. The tech has existed for quite some time to implement them in theory. Body hackers have already done so a decade ago.

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?

[asa400]

It's a question of incentives.

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.

[pinkmuffinere]

Not to invalidate your experience, but I think both of you feel this way because “you only want what you don’t have”. There are different kinds of joy that come from being impactful, and different kinds that come from moving fast. If only we could move fast and be impactful :’(

[vjvjvjvjghv]

I could be fast and impactful. Just in a negative way. The problem is that I come from the software dev side so I tend to be less interested in the medical side. It’s the same in a lot of safety critical. There is a lot of mundane work to tick the necessary checkboxes. There isn’t much that is interesting from a technological side. Maybe the result is interesting but getting there takes a lot of extremely boring work.

[jacquesm]

Maybe you should change your line of work. If you're that unhappy about what you do in spite of the fact that what you do is orders of magnitude more important than the next move-fast-and-break-things-advertising-driven-unicorn then that suggests to me that you should let someone else take over who does derive happiness from it and you get yours from a faster paced environment.

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).

[vjvjvjvjghv]

I am retiring next year. So that should solve my problem :). I don’t know how other medical device companies are working but in mine leadership is dominated by people who know medical devices from a sales or medical perspective. Software is kind of secondary to them although it’s becoming really important. A lot of our processes aren’t very good for software so we end up doing a lot of work that makes no sense and makes the product actually worse. It’s better not to fix bugs because a new release will take months of paperwork. The requirement structure doesn’t map to software but the SOP isn’t written by people who known software. It feels a little like the development speed of NASA with the SLS vs SpaceX who are basically doing everything faster and cheaper while still having high reliability . My company is NASA here. Just very frustrating

[jacquesm]

I've worked with a startup in the medical device space. Well funded. They were indistinguishable from most other startups, except in one detail: they did everything right. They made some extremely high tech stuff, very lightweight, and technology wise they were closer to watchmakers than to software and hardware people. I loved working with them and helped them to improve their yield (their QA was so strict that of their initial couple of runs more than 2/3rds of the devices got binned for the smallest infractions).

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!

[vjvjvjvjghv]

From what I have seen startups have it a little easier. They are usually focused on one product and often just get acquired before having to go to market themselves. Selling multiple products worldwide and complying with regulations is a totally different ballgame.

[nickpsecurity]

What you describe sounds nothing like most, safety-critical development I've heard of. Whereas, I've heard the other person's story countless times when I studied high-assurance systems. Very slow, top-down, process-heavy, paperwork-heavy, and outdated tools.

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?

[1over137]

Lots of the moving fast stuff is very impactful, just often in a bad way.

[sinuhe69]

What is in this particular case that requires outdated tools? If they are code, certainly you can write them on VS Code or whatever you likes, and only need to compile and load on the original tools, can’t you?

[vjvjvjvjghv]

It’s more the library and language side. Typically you are years behind and once a version has proven to be working, the reluctance to upgrade is high. It’s getting really interesting with the rise of package managers and small packages. Validating all of them is a ton of effort. It was easier with larger frameworks

[jonp888]

Sometimes it's because you need to support ancient esoteric hardware that's not supported by any other tools, or because you've built so much of your own tooling around a particular tool that it resembles application platform in it's own right.

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.

[vjvjvjvjghv]

That’s what we often do. Develop with one set of non validated tools but in the end put everything into the validated system for submission.

[SoftTalker]

You need tracability from requirements down to lines of code. It's a very painstaking process.

[vjvjvjvjghv]

Painstaking and often done with terrible tools and badly written requirements.

[m463]

> develop with outdated tools

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.

[justinclift]

Oh, you could "move fast and break things" in your current job. For a while... ;)

(please don't)