Every time I see a Software Development article, I always try to read them with the hope that I’ll learn something I didn’t know before. I’ve been in the software industry for longer than I care to admit and I’m convinced you can teach an old dog new tricks. Thus I read an article by Malinda Elien in the Medical Device and Diagnostic Industry (MDDI) titled “Debunking the 'It's Just Software' Myth”. For those of you initiated in software development, Ms. Elien makes perfect sense, and yet you probably already know this. She points out that changes to software architecture can see exponential increases in cost as a product development effort progresses. She does a rather nice job of summarizing some development strategies to reduce the probability of late changes in software requirements, which could ultimately cause a delay in the release of a product development effort.
Those strategies are: Fundamentally, Convince the Team that “It's Just Software” Is Not the Right Attitude; Develop Complete Requirements; Use Breadboards and Test Often; Bound the Requirements that Cannot Be Defined; Involve the Software Development Team in Product Architecture Selection; Stick to Requirements that Drive the System Architecture; Decide Feature Implementation Order with Purpose; Encourage Incremental Testing Releases; Allow Time for UI Iterations and Usability Testing; and finally, Once in Verification Testing, Only Consider Critical Software Changes.
She’s right on and goes on to say that changes are inevitable during product development. We need to understand and manage the effect of software requirement changes at the different stages in the development process to enable smoother development implementation and integration, and allow for appropriate risk mitigation activities throughout. We need to understand the impact of requirements on the system architecture, develop with purpose, and test early and often to help validate requirements during the design process. If we do this, we will minimize the effect of changes during the medical device development effort.
Unfortunately, for software developers, this makes perfect sense. For all others, they think “it's just software” and of course we can fix hardware issues found during validation testing with a quick software fix. Of course! That very first strategy that Ms. Elien talks about, “Fundamentally, Convince the Team that 'It's Just Software' Is Not the Right Attitude” is also the toughest one to crack. If software changes are considered by the team to be as costly as hardware changes, they will likely perform software-critical testing early and bring problems forward more quickly, thus reducing the cost to fix issues later in the development effort. This premise holds true for hardware issues as well and that’s the crux of the problem. Software issues are just as expensive as hardware issues to fix as the product development effort proceeds.
But how do you convince the team that “It's Just Software” is not the right attitude? This is where the old dog can teach you some new tricks. Use experience and fate (i.e., changes are inevitable during product development) – I knew all of those years of experience would pay off some day. Watch or experience the ripple effect of changes on the product development effort – they definitely affect the timing, cost, and quality of product development efforts.
So don't fall into the “it's-just-software” trap. Use these observations during your next development effort to get the most efficient use of resources, ensure your investment will return the highest value and best meet the intended clinical outcome you’re trying to obtain.
In my next blog I'll discuss “Standards and Guidelines, Yes!” – that always gets an eye-roll from clients. More next time!