Hacking, Developing, and Engineering for Regulated Software
Subscriber Benefit
As a subscriber you can listen to articles at work, in the car, or while you work out. Subscribe NowHow would you characterize your software development style – hacker, developer, engineer, or computer scientist? Of course, the vast majority of readers of this article will not have a “software development style” and, other than trying to forget the struggles from a past “intro to computing” course, this question may not seem relevant to you. However, if you are involved with medical devices that include any software component, having a better understanding of software development style will be beneficial.
Let me start off by saying each of these software development styles has utility and purpose in development of regulated software. Providing a quick definition of the styles, hacking can be described as writing code without specific requirements and little planning with the goal of creating software that produces a result quickly. The developer style is characterized by having requirements, following prescribed standards for development, and producing software that meets the requirements and is relatively “bug free”. The engineer style includes the developer style and also involves designing software that can be evolved to meet changing requirements and can scale to higher volumes of data or higher numbers of users. Finally, the computer science style is focused on optimizing the tools, algorithms, and techniques used for all styles of software development.
Relating these styles to a context we are all familiar with – house construction – a hacker style would be efficient for building a treehouse, the developer style is appropriate for following a plan to build a deck, the engineer style is appropriate for constructing a house with a blueprint with the house comprised of subsystems like plumbing, heating/cooling, flooring, etc., and the computer scientist style is useful for creating the best tools – pneumatic nail guns, cordless drills, and the like – used for construction. Each of the styles, when applied to the appropriate construction project, strikes the right balance of time investment for the desired finished product.
The majority of regulated software is developed with the developer or engineer style, as the FDA mandates software should be developed with requirements, developers be trained and follow a process, and testing is done against requirements. The engineer style may not be necessary for regulated software components that are of low to moderate complexity, such as in systems that are for a single user or software that runs on a stand-alone device. The engineering style would be appropriate if the device has multiple users, is cloud-connected, or has specific performance or future expandability needs.
The hacking style is appropriate in regulated software development for prototyping early versions of software outside of design controls to gather feedback on usability, or to determine if specific algorithms or device interfaces are feasible. The hacking style generally does not allow traceability or generate evidence of following processes, so the output of hacking is typically not used in a finished regulated software product. However, the value of confirming usability or proving feasibility of an algorithm is well-worth the investment of hacking and then re-writing in another style.
The computer science style underlies all of the styles used in regulated software development in that tools and languages are necessary for developing in any of the other styles. Depending on the size of the software development team, a computer scientist may not be involved full-time, but some team member or members will need to be take responsibility for identifying the appropriate languages and tools for use.
The most important point to leave with is this: experienced software developers and mature software development teams will make use of all of these styles and will have an understanding of when each of the styles is most appropriate.
So, now I ask you again, “what is your software development style?” I hope the answer you hear back from yourself or your team is “well, it depends."
Brad Graves is a member of the technical staff at The RND Group.