jump to navigation

The Quality You Don’t See October 20, 2013

Posted by Jiaqi Wu in Security.

I used to work at a large medical device company as a software engineer. We produced CT scanners, MRI scanners, and a whole host of other medical devices. A medical scanner of that caliber in the right hands can save lives. In the wrong hands, they can be deadly. In this business, one can imagine the stringent processes in which safety of these devices is ensured. Every feature goes through numerous stages of technical design reviews. Every line of code is inspected by hand. Every code commit to CRM is tracked. Once in a while an auditing body comes around and spends months auditing every single piece of activity performed in our development process. It is safe to say that on paper, we were doing everything we possibly could to ensure the safety of our patients. However from the inside, I saw one glaring problem.


At the time I was a very recent college graduate who had only been working in industry for about a year. I was optimistic and excited to receive whatever project I was put on. The features I was working on were isolated. I was essentially a one-man team delivering a small set of features to the user interface of one of our MRI scanners. My job was to write some code for a few different features and commit them to our code base that was going to ship in this next year’s program.


Being a fresh graduate, my skills were varying. I was a quick study, but working alone with only some guidance was a struggle. As deadlines loomed overhead, I realized many of my features were falling behind. Was it my fault? Had school not prepared me for the high pace of the “real world”? To my dismay, we had our program status meeting coming up. Repeatedly in the past weeks, I was confident that I could finish my tasks. I gave a green status despite my slowly growing concerns of the program schedule. I did not want to be the only person holding everybody back. However this week would be the week that I had to admit that things were falling behind. It was a matter of honesty.


To my surprise, as the meeting progressed, it was easy to see that I was not the only one feeling the schedule pressure. Half of the features in the program were all behind schedule. When my turn came, my news was no worse than the last guy. We moved ahead with the meeting and the program manager, slightly flustered, decided to push back our dates. With new relief, I began working away again at my feature.


This may seem like a common trend in project management today. As with any individual, we feel pressure from the one who signs our paychecks every week. My job is to write good code and deliver my features. The program manager’s job is to deliver a program. I am measured by how many features I can deliver. The program manager is also measured by how many features he can deliver as well. The problem is, the program manager is bound only to his or her words. Instantaneous short-term recognition is given when one can give an above average promise. Estimate a 12-month program at 10 months? Add 10% more features this year compared to last year? No problem, “I can give you that”, says the program manager. Then the obligation gets delegated down to the software development managers and ultimately, us.


In project management, there is the great trifecta which limits project scope: time, money and resources. In this case, if you cut time or add scope, but do not add more money or more resources then your project will lose something. In our case, quality is what will go. I cannot imagine how many times I have seen corners cut in the programs I’ve been through because of tight schedules.


Unfortunately, the software that we develop is not a video game where a small bug can be patched later and we can let crashes here and there slide until then. If there is a problem in our software, somebody could die. This is the real issue in project management today. Projects are driven with the wrong motives. In a large corporation, money, stock prices (aka money), annual reviews (aka money), and promotions (aka money) are what drive projects. When the motivator itself is not directly related to ethics, then ethics will not be the top priority.


Exactly how is this all an ethics issue then? It is quite simple really. If you as a project manager give an unrealistic date for a project or a program, then you are lying. This is an ethical issue just like if I were to cut corners in test cases, skip processes with assumption that I’ve done everything correctly, and other blatant forms of ethics violations. Knowingly committing to dates that you know cannot be met puts patients at risk in this industry.


It really scares to think after seeing the standards where I used to work that a similar mindset probably exists at companies like Boeing, which build aircraft, or firms that build bridges who have tight deadlines and rush to deliver features. I am riding on a plane right now and thinking to myself if the same caliber of program managers that I used to work with were involved in building the operating system on this airplane. I wouldn’t be surprised that the pilot actually has to jiggle the on off switch on a critical device in the air every once in a while to keep it running. As long as it passes all the regulatory bodies, audits, and predefined standards, the product is deemed safe. Oh well, only the surface level success rates matter I guess. How they convince anybody that their products pass inspection is beyond me.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: