Software Engineering checklist

On Saturday December 13 2014, I had the opportunity to attend a University of Minnesota Computer Science and Engineering presentation by David Parnas on the topic of Software Engineering, Why and What. Dr. Parnas is an early pioneer of Software Engineering since the 1960's. He presented ”what Software Engineers need to know and what they need to be doing”. Dr. Parnas presentation contained information about the differences between Software Engineering and Computer Science. Theses are two terms that I previously had articulating the differences so to help me on my journey of mastery, I thought I would write about this topic.

Science and Engineering are fundamentally different activities. Science produces knowledge and Engineering produces products.

Computer Science is a body of knowledge about computers and their use. The Computer Science field is the scientific approach to computation and its applications. A Computer Scientist specializes in the theory of computation and design of computational systems.

Software Engineering is the multi-person development of multi-version software programs. Software Engineering is about the application of engineering to the design, development and maintenance of software. Software engineers produce large families of programs that requires not only a mastery of programming but several other skills as well.

Dr. Parnas presented his list of skills a Software Engineer must to know and challenged the audience to use it and extend it.

Software Engineering checklist

  • Communicate precisely between developers and stakeholders.
  • Communicate precisely among developers, others who will use the program.
  • Design human-computer interfaces.
  • Design and maintain multi-version software.
  • Separating concerns.
  • Documentation.
  • Using parameterization.
  • Design software for portability.
  • Design software for extension or contraction.
  • Design software for reuse.
  • Revise old programs.
  • Software quality assurance.
  • Develop secure software.
  • Create and use models in system development.
  • Specify, predict, analyze and evaluate performance.
  • Be disciplined in development and maintenance.
  • Use metrics in system development.
  • Manage complex projects.
  • Deal with concurrency.
  • Understand and use non-determinacy.
  • Apply mathematics to increase quality and efficiency.

All the capabilities on the list have several things in common. They are all subjects that require a deep level of understanding to get right. All of the skills involve some Computer Science, and Mathematics. They are fundamental skills and not related to a specific technology. The technology changes but the core concepts of Software Engineering do not change.

What resonated the most with me was the need for discipline. Engineers are not born with disciplined work habits, they have to be taught. Writing good software requires discipline in the entire software lifecycle.

Software maintenance requires even more discipline that the original development. One of Dr. Parnas' techniques for teaching Software Engineering is to have students analyze, optimize and maintain code that someone else wrote. Did any other Software Engineers get that kind of training in school?

To learn to do, you must do

Sometimes experience is the greatest teacher

Maintaining a large software project (that I did not write) was one of the most difficult projects I worked on in my professional career. To maintain software you did not write is incredibly difficult because you have to learn what the software is supposed to do which is often not what it actually does. With little documentation to go on, my team was forced to read the mostly uncommented code. I often had the impulse (and pressure from management) to “ship” a quick fix to a customer problem, but learned that all changes no matter how small had to be carefully considered and tested before it could be released. Bugs or errors in the field are bad but can be very costly for a company to fix. It takes discipline to maintain large software products because a fix to one problem could create another somewhere else. This maintenance project changed how I wrote software because I did not want other people to have the same difficult experience that we had. To this day I obsessively comment any code I write for software projects.

Thanks to Dr. David Parnas for this list, I will try to use the information about Software Engineering on my continuing journey toward mastery.