Strategic Software Development Tactics for MedTech

​Jeff Gable, founder and principal at Gable Technology and cohost of the Agile Embedded podcast, led Square-1’s Lunch & Learn on software development for medical devices. He spoke directly to managers and executives about the common failures he sees, and the practical fixes teams can apply today.

Why software looks done long before it actually is
Software teams often report being 80 to 95 percent complete. Then progress stalls. That last stretch eats time and budget. Jeff calls this the 90 percent trap. The cause is usually twofold: unclear requirements up front and a fuzzy definition of done.
Managers should demand clarity early. Mock up user interfaces. Define core flows. Spell out what “done” means for each feature. Done is not just code that compiles. Done is integrated, verified in product context, documented, and traceable.

Make requirements real, not optional
Agile does not mean no requirements. Agile means learn quickly and adapt. For regulated software that runs on devices, early requirements matter for both software and hardware. If a software risk requires a hardware limit, managers must know early. Requirements written poorly or late create rework and delays.
Actionable step: create high fidelity mockups for user flows and capture acceptance criteria before deep implementation work begins.

Define done and measure progress honestly
Software teams should break “done” into clear, testable steps. Unit tested. Integrated. Verified in system. Documented and released. If you want percent complete, make percent meaningful. Track progress across those steps instead of using a single vague percentage.

Don’t ignore software in your risk analysis
Too many teams treat code review as the mitigation for software hazards. That is not enough. Software risk analysis must be performed early and feed hardware and system decisions. If a dangerous software output can be prevented by a hardware limit or a system interlock, design that in early. Waiting until the end to discover those needs is costly.
Actionable step: require software hazard and risk analysis in parallel with architecture and requirements work.

Keep prototypes and production code separate
A prototype proves an idea. It is not the same as production software. Prototype code often covers the happy path only. Production code must handle edge cases, error handling, safety modes, and full documentation. Treat prototypes as throwaway experiments. Use learnings, but rewrite production code under design control.

Invest in modern ALM tools and automated verification
Tracking requirements and traceability in Word and Excel creates friction and human error. Application Lifecycle Management tools automate traceability, link requirements to tests, and simplify changes. Static analyzers and automated unit test frameworks catch regressions early. Open source tools are now acceptable in many cases and far better than manual tracing.
Actionable step: evaluate ALM tools that fit your budget and integrate static analysis and CI test runners into your pipeline.

Agile means rapid learning, not sloppy planning
Jeff defines Agile as rapid learning and continuous feedback. For embedded and regulated software, Agile requires tooling and processes that remove friction for changes. When requirements shift, teams must be able to update traceability and run regression suites without heavy manual work.

AI is a tool, not a replacement for expertise
AI can accelerate certain tasks. It can generate scaffolding or prototypes quickly. It can suggest test cases or refactor code. But AI cannot replace deep domain knowledge. Use it to amplify experienced engineers. Keep control by reviewing everything AI produces, unit testing it, and limiting AI to well defined, small tasks.

Quick checklist for leaders

• Require clear UI mockups and acceptance criteria before major implementation.
• Define “done” across coding, testing, integration, and documentation.
• Mandate software risk analysis early and treat software risks as drivers for hardware or system changes.
• Separate prototype work from production work and plan time to rewrite as needed.
• Adopt an ALM tool to automate traceability and reduce manual effort.
• Integrate static analysis and automated unit testing into CI pipelines.
• Use AI selectively. Keep experienced engineers in the loop.

Conclusion and next steps
Small tactical changes can shorten timelines and lower product risk. Leaders who focus on clear requirements, honest definitions of done, and modern tooling will see big returns. Jeff’s Lunch & Learn is full of practical examples and real world guidance for teams building device software.