Few years back I had worked with a Japanese customer for a health care imaging project at their site. I was relatively new to the domain. Most of the development team was there in India.
We had some solid requirements and prototyping on some new features. I had demonstrated one of the prototypes integrated to the product which essentially play back the images aligned to the ECG cycle acquired from the cardiac patient. The feature helps the sonographer to export the data as AVI. I simply tested the feature and quickly setup the demo as we’ve already crossed the deadline. Things were working just fine. This I had already seen in the prototype earlier. Fine. I demonstrated the feature successfully and was happy about it. I requested him to to try the new feature to get more feedback from him. He happily took over the system.
He simply registered a patient, then acquired the images along with ECG. He went on reviewing the acquired images, then he exported the cycles as AVI to the patient. He quit the application and opened the patient browser if appears under the current patient. Yea it’s there. I dint feel anything bad when he registered one more patient and start the application again. (Application won’t quit, it will be residing in memory always. They simply hide the window and release the resources and keeps on waiting for commands from parent application). He did the very same procedure again. It was working I was happy again. The progress bar has been displayed again and finished the export. Then he took the patient browser once more. Surprisingly the data wasn’t there under the current patient.
As I knew the code base well, I figured out within seconds what made it to disappear the data. I told him “I’m sorry, the new patient event not handled well. The code isn’t resetting/replacing the patient ID with new one. I can fix this. It’s just one line modification” and I was about to go back to my desk to modify the source.
He stopped me and smiled and explained, “Sarath-san, are you realizing that this is a serious security issue?” I could not fully understand what he really meant with security issue.
I did not reply. He continued “For programmers, it’s a one line code modification which takes to fix this issue. But think from a customer perspective. If you went a hospital with some small chest pain and the next patient is coming with some serious cardiac problem and what if his data being exported to your ID, then the doctor gives you the wrong treatment?”
The example was perfect. I could not think of a major heart surgery because of a system/sonographer’s mistake. That was kind of eye opener. Even after all these years I still remember the story.
Most of the time, programmers are either instructed to do some part of the code without having understanding of the impact. To make and maintain better software, it is also important to understand what is the big picture. What is the real impact. Always remember the issues being found during the development time is easy to fix, once it’s delivered to the customer site, the cost will be N times more, depends on the number of customers we’ve and the cost of deploying the patches. It starts from requirement capturing to implementation. It’s responsibility of the person who captures the requirements to test/inform the major uses cases, aspect and impact of the features. On the other hand, when we’re implementing something, it’s solely our responsibility to properly understand the requirement, big picture of this requirements and the impact area. It’s equally important to do regression testing to make sure that the existing functionalities aren’t broken.
When less competent people leads these activity there’s a high chance to have the information in pockets and do not explain the requirements properly to make sure that they’ve better control over the project (trust me, there are people). But that is actually making the product and themselves worse. Also it’s developers responsibility to bug the people enough to get maximum information and clarify the requirements.