Why Good Programming Isn't Enough

Good programming does require talented individuals who can write code well, but in actuality it also requires much more. No matter how talented a programmer is, their code will not be excellent until it has been produced within a framework of solid software design procedures.  What comes to mind when you think of a software programmer?

Share this
Share this

Good programming does require talented individuals who can write code well, but in actuality it also requires much more. No matter how talented a programmer is, their code will not be excellent until it has been produced within a framework of solid software design procedures.  What comes to mind when you think of a software programmer?

If you are like many people, the image may be a bit mysterious—perhaps a young, creative, techno savvy person who is able to spend hours in a darkened room and emerge with elegant code. Or, maybe the seasoned sage whose speech is peppered with acronyms, which refer to aspects of software code but actually seem to form their own, separate language. I like to affectionately refer to these images of the programmer as the "Pizza and Mountain Dew" effect: good programmers disappear into their preferred workspace, get into a coding groove, and if you just keep supplying pizza and Mountain Dew, they will keep spitting out code.

Whether the quip about a typical programmer's diet is accurate or not (it usually isn't), does the mysterious image hold? Does good programming emerge from the work of a single, talented mind?

Far from being mysterious, software design is a rigorous, repeatable process that occurs before, after and while code is actually produced. Good software design applies principles of requirements gathering, engineering, project management, user interaction, risk management, verification, and validation to the production of software. It ensures that the output—actual code—meets the rigorous safety and reliability needs of the medical device industry. These needs include inputs to the design history file (DHF) as required in 21 CFR Part 820, contributions to the risk management process, and compliance with software-related medical device standards (like IEC 62304).

 

Prev Post
Next Post