What is Software Engineering?

May 21, 2010

This post is a follow-up to my earlier blog on Software Certification. Certification is a complex topic.  Before getting too far into a discussion on certification, let’s look at the work we call software development.

World wide there are millions of individuals who develop software for a living and they go by many names: programmer, software developer, software craftsman and software engineer.

From a work content point of view, the work of software development appears similar to the work that engineers perform and there is a recent trend to call individuals who develop software, Software Engineers.

For the past 20 years, I have been a consultant to dozens of companies assisting them improve their business processes and improve their ability to develop software. During this time, I have taught Software Engineering as an adjunct at DePaul University in Chicago.  This past Winter Quarter, I taught a Software Engineering Process class with a focus on Agile and Lean software engineering.  After this class I felt that my old definition of Software Engineering was inadequate and felt the necessity to develop the current definition as follows:

Larry’s Current Definition of Software Engineering

“Software Engineering is a profession that uses sound engineering principles, processes and practices and a body of knowledge to propose, design, develop, deploy, operate, maintain and retire computer software solutions over their useful life that people will buy and use to solve real world problems.”

Within this definition the Software Engineer becomes responsible for the overall software solution from the initial idea through design, development, deployment, operation to retirement.

This definition also accommodates the various sub-specialties of Software Engineering that we see in practice today such as: Business Analyst, Data Base Engineer, Infrastructure Engineer, Network Engineer, Software Developer and Systems Administrator.

Why develop my own definition of Software Engineering?

For the last 20 years I had been using a definition of Software Engineering by Fritz Bauer from 1968 (see below).  That definition was workable for a long time, but recently I felt that that it needed to be broadened to better encompass the full software development life cycle.

Before I wrote my own definition of software engineering, I researched several other definitions: one on Wikipedia and one defined in IEEE’s Software Engineering Body of Knowledge (see below). Neither of these definitions satisfied by current view of software engineering in terms of the breadth or depth required to “engineer” software in the real world situations that I saw every day in my consulting work.

Software development is a complex process.  The software development process begins with an idea, continues with the design and development of a solution followed by operating the solution in production for a period of time and eventually retiring the solution as described below:

  • Envision: The “engineering” of a software program begins when an individual, often called the “user” determines they have a need for something new or a “developer” envisions a new way to solve a problem.
  • Propose: The “engineering” continues with a proposal to obtain funding for a project to develop the solution.
  • Design: Once funding is obtained, “engineering” designs a solution to the problem.

  • Development: Next, “engineering” develops a working version of the solution.
  • Deploy: Once an initial version of the system has been developed, further “engineering” is usually needed to successfully deploy the solution into operation.
  • Operation and Maintenance: As the solution operates and its use grows, there is a need to “engineer” refinements into the solution for it to continue to grow and satisfy changing conditions.
  • Retirement: Eventually, the solution can not be cost effectively refined and it must be replaced by a “new” solution and the cycle continues.  Even in this stage, there is a need to “engineer” the graceful retirement of the “old” solution.

Although this may seem like a linear life cycle, there is usually considerable iteration between the various stages.  Throughout this life cycle, there is a need for a “software engineer” to formally or informally make use of a wide variety of principles, processes, and practices such as:  requirements definition (or product backlog development), coding and coding standards, configuration management, testing and a mechanism of handling changes (Change Control or Iterations) to name a few.

Other Definitions of Software Engineering

Fritz Bauer’s Early Definition of Software Engineering

“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.”

Fritz Bauer, 1968

Wikipedia

Software engineering is a profession and field of study dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build.

See http://en.wikipedia.org/wiki/Software_engineering for more details.

IEEE Computer Society

The IEEE Computer Society‘s Software Engineering Body of Knowledge defines “software engineering” as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.[6]

See http://www.computer.org/portal/web/swebok/html/ch1#Ref1 for more details.

Although the Wikipedia definition mentions design of software, it does not focus on the full life cycle and adds constraints such as “more affordable” that are extraneous.  The IEEE SWBOK definition includes operation in the life cycle, but does not mention design.  It also adds a statement around “quantifiable” which often can not be accomplished in the real world.

More posts on this topic in the future!

Leave a Comment » | Software Engineering | Tagged: , , | Permalink
Posted by Larry D

Software Certifications

April 29, 2010

At the APLN Chicago meeting on Thurs, April 21, 2010 we had a good discussion on Certification and Certificates. The discussion focused on the reasons for and against certification as follows:

Reasons for Certification:

1)      As guide to learn a domain

2)      To get past hiring filters

3)      To demonstration that the individual has learned a domain

4)      To socialize with peers w/similar knowledge, challenges and interests

Reasons against Certifications:

1)      Doesn’t show true capability – especially when Certification occurs after a 2 day class without a test (or even 1 week class with a test – I’m thinking of PMI here);

2)      Certification turns skills, knowledge, experience and knowledge work in general into a commodity

Some of my thoughts on the issue that were not discussed at the APLN meeting:

I believe that Certification has turned knowledge work into a commodity without adequate proof that it can be turned into a commodity.  The use of Certifications for positions like Project Manager, Tester, Business Analyst and Scrum Master has made the life of a hiring official easier, but I doubt that it has improved the quality of the workers hired.

Certification is not the way to solve the problem, especially when Certification means attending a 2-day class (or even attending a 1-week class and test).  Pretending that a Certification will fix the personnel selection problem is foolish and dangerous.

Where’s the Beef?

I would like to see a hiring official show me defensible personnel selection data that shows that Certifications has improved the quality of the work force hired.

In fact, I believe that Certification in the Computer Industry has led to the outsourcing of many US jobs to cheap foreign labor without adequate demonstration that the foreign labor can in fact deliver the same results.

Assessing Talent is difficult.  It is difficult in the software development area and it is difficult in sports teams as well, as most fans of Chicago area teams know.

Interview based personnel selection systems (which most organizations use) have low validity with correlation coefficients between 0.20 and 0.30. This means that the interview based selection systems account for between 4% and 9% of the variability between interview ratings and job success.  Not a number you would want to “bet the farm on”!

Improved interviewing skills, job simulations and greater focus on grooming internal employees will provide some improvement, but current personnel selection techniques are just not very effective.

It takes many years of continued demonstration of good skills, knowledge and experience in real life situations to become a licensed Medical Doctor.  If we want to formally assess talent, than we should State License Software Engineers in a way similar to the Medical Profession!

Leave a Comment » | Software Engineering | Tagged: , | Permalink
Posted by Larry D