Introduction 🔗
Our team recently read most of Ward Farnsworth’s, The Socratic Method: A Practitioner’s Handbook, to see whether we could apply the Socratic Method to our pull request reviews, design discussions, or elsewhere. The book is quite approachable. A key insight is that you can use the Socratic method with yourself. This is especially potent, and time-consuming, when you write down the dialogue. Each person in the dialogue may be different part of your thought process. Writing the dialogue forces you to confront your own inconsistencies.
Besides reading the book, we also wrote our own dialogues. This is one such dialogue, which ultimately lead to applicable insights about how to structure our software development processes. It attempts to focus on consistency and to use concrete analogies to propel the discussion forward.
If you can use help applying agile methods to the FDA’s design controls regulation or IEC 62304, we can help you develop a process that keeps your software productive and your users safe.
Dialogue 🔗
Dijkstra: I’ve been sitting in on a weekly discussion at a software engineering company.
Holden: Why?
Dijkstra: I want to know what happens next—what everyone is talking about.
Holden: What is everyone talking about?
Dijkstra: Last week, the group spent an hour distinguishing software maintenance from software construction.
Holden: Really? You may be wasting your time.
Dijkstra: Some weeks are more interesting than others, but I thought the software-maintenance discussion was worthwhile. The terms we use have a profound and devious influence on our thinking habits, and therefore on our thinking abilities. Thus, knowing the essential difference between software construction and maintenance will enable an engineer to think clearly about the two.
Holden: I’m skeptical. When specifically is the distinction useful?
Dijkstra: I’ll borrow an example from the group: if a fellow team member is competent at construction but not at maintenance, then the distinction lets you recommend maintenance-specific training resources.
Holden: That’s assuming there are maintenance-specific training resources to recommend. If the same tools, techniques, and methods are used during construction and maintenance, then any book to help with one would help with the other.
Dijkstra: Of course! Distinguishing the indistinguishable is pointless. I’m assuming that there is a distinction to be made.
Holden: Well, if you think there’s a real distinction, what is software maintenance?
Dijkstra: My ideas are somewhat mixed with the ideas shared in the group discussion, and my connection was unstable, so I didn’t hear everything. Thus I can’t attribute everyone’s ideas properly.
Holden: I only care about the ideas, not who said them. So, what is software maintenance?
Dijkstra: I’ll begin with an analogy. Buildings are constructed, occupied, and then maintained. Building maintenance may include periodically inspecting the building’s structural integrity, fixing roof leaks, cleaning the windows, and occasionally repainting the walls. Building construction involves laying the foundation, laying out the structural support, finishing the exterior, the electrical work, plumbing, and so on. Building maintenance is quite different from building construction.
Likewise, software maintenance is quite different from software construction. Changes are easier to make during software construction because you don’t have users. Once you have users, you must consider their data and their habits. People will complain if you lose their data or change a feature they like. Thus, the maintainer must be more careful than the constructor. Here are some examples of software maintenance: monitoring the database and backups, patching cybersecurity vulnerabilities, cleaning out bad data from your database, and occasionally refreshing the user interface.
Thus, software maintenance is all the activities required to support a software system with users.
Holden: Is identifying and fixing a software bug a part of maintenance?
Dijkstra: According to this definition, it would be if you have users.
Holden: What if you don’t have users?
Dijkstra: Then it wouldn’t be part of maintenance.
Holden: Do the users affect how one identifies and fixes a bug?
Dijkstra: They wouldn’t affect how you identify bugs, but they may affect how you fix them.
For example, imagine if the database column you use to store WiFi names only supports Latin characters, but you realize you need to support Japanese. Your fix requires you to modify the character encoding used in that database column. If you didn’t have users, you could change the encoding, but since you have users, you need to migrate their data from the old encoding to the new encoding. And it would be even more complicated if you needed to keep the application running during the migration.
Likewise, building repairs are more complicated if you can’t kick out the occupants while you’re working.
Holden: This is an insightful point. I see how users would affect how you fix a bug. Won’t they affect how you construct new features too? Once you have users, is building a new software feature part of maintenance?
Dijkstra: No, I don’t think it would be.
Holden: How can you distinguish bugs and features?
Dijkstra: In my example, I imagined that the client expected Japanese WiFi-name support. Thus, it is a bug because they expected it, and it wasn’t there. If they hadn’t expected it, then adding it would be a feature.
Holden: So are bugs and features distinguished by client expectations or possibly legal contracts?
Dijkstra: That is what I’m saying.
Holden: Would you agree that bug fixes and feature additions are the most significant activities required to support a software system with users?
Dijkstra: Yes.
Holden: Then it seems software maintenance and software construction are distinguished based on client expectations, which contradicts what you said earlier.
Dijkstra: How so?
Holden: Couldn’t a client find a bug before you have users?
Dijkstra: Yes.
Holden: So, would fixing the bug be part of software maintenance or software construction?
Dijkstra: I see your point. Perhaps fixing a bug is software maintenance once you have users, but software construction before. Adding a feature is always construction.
Holden: That does fix the inconsistency in the definitions, but your combined definition seems useless.
Dijkstra: Why is that?
Holden: Earlier, you said that distinguishing maintenance and construction was useful because each activity used different tools, techniques, and methods.
Dijkstra: That’s right—this is why the distinction is useful to engineers. The distinction could be useful to other people for other reasons. E.g., distinguishing a bug and a feature may determine who pays for the fix.
Holden: True. Lawyers and business people may find different definitions useful, but let’s stick with what definitions will be useful to engineers. You said that adding support for Japanese WiFi names will depend on whether you have users or not, right?
Dijkstra: Correct.
Holden: You also said that adding support for Japanese WiFi names could be a bug, and thus maintenance, or a feature, and thus construction, depending solely on client expectations.
Dijkstra: True.
Holden: Well, then it seems that according to your definition, maintenance and construction end up using the same tools, techniques, and methods, after all. If this is the case, then why is the distinction useful?
Dijkstra: Good point. Then let’s see if we can find a more useful definition. Let’s say that adding new features to an application with users is also software maintenance. After all, once a building has occupants, perhaps the distinction between feature upgrades and maintenance isn’t meaningful. Furthermore, this is how the IEC 62304 standard defines software maintenance.
Holden: I don’t think your analogy between buildings and software is valid here:
I’ve read the landmark designation reports for dozens of buildings in New York City. These reports record a building’s major renovations. Usually, there aren’t many. Even century-old buildings rarely have more than two or three in their lifetime.
Software applications aren’t like this. Many applications, especially since 2010, continuously deploy small changes. New companies start by building small applications and then slowly add to them to understand their market better.
If buildings were built like this, a construction company would start with a tiny home, have their first renter move in, and add new rooms, stories, and tenants. After a couple of years, if all goes well, the tiny home will be a skyscraper. This is absurd!
If you define software maintenance as any work that’s done after you have users, you may be doing software maintenance for most of the project!
Dijkstra: Medical device software isn’t like the software coming out of Silicon Valley’s “fail fast and break things” culture; you’ve got to get it right the first time. The “things” being broken are people, and that’s just plain wrong. Not only that, the FDA’s Design Controls Regulation, and Design Change, in particular, requires you to treat released software differently than unreleased software. IEC 62304 does too. This is why that standard distinguishes the maintenance process (section 6) from the development process (section 5). The latter must implement change controls (section 8.2).
A lot of medical device software is like a building. The first version is released, and any subsequent changes are infrequent and slowly made.
Holden: You’re right that medical device software can’t “break things.” But as medical devices become more connected, they need to deal with ongoing cybersecurity threats and integrations with other systems—both require ongoing changes. Likewise, AI models need to be updated as we collect more data and new imaging systems come onto the market. As a result, the pace of change in medical device software is accelerating.
Dijkstra: Now that you mention it, someone in the weekly discussion group said something about “accelerating progress in the medical device industry.”
Holden: Don’t get distracted. I wasn’t finished!
The analogy between medical device software and buildings is becoming less valid as it changes more often. This change is related to the shift from waterfall methods—with design review gates between planning, requirements gathering, architecture, verification, validation, and design transfer—and agile methods—with design reviews set after planning and between sprints. The latter approach works better with fast change. You should check out AAMI TIR 45, “Guidance on the use of agile practices in the development of medical device software.” It demonstrates how agile methods work within design controls and IEC 62304.
Nevertheless, you’re right that IEC 62304 defines maintenance as all of the work that’s done after a regulatory release. As we discussed, this isn’t a useful definition for engineers, even if it’s useful for regulators.
Dijkstra: Then what definition would be useful to engineers?
Holden: Perhaps software construction is any work that involves meeting new requirements, and software maintenance is any work that involves requirements that previously had been met.
Dijkstra: How is this different from what I’d said earlier: Maintenance is fixing bugs, and construction is about adding new features?
Holden: It’s similar. You got caught up in how to define a bug vs. a feature. You said the client or the contract distinguishes the two. I think we can let the engineer make the distinction. Maintenance is any work related to a requirement the engineers thought they’d already met.
Dijkstra: Ok, the definition is clear. Is it useful? Does it guide the engineer to select the appropriate tools, techniques, and methods?
Holden: I suspect it does, but I have to go, so I won’t be able to dig into this further just yet. It was nice talking. Do you think you’ll keep attending the 10x talks?
Dijkstra: We’ll see.
We can help 🔗
If you can use help applying agile methods to the FDA’s design controls regulation or IEC 62304, we can help you develop a process that keeps your software productive and your users safe.
