Moving Software Engineering to Professional Status – (C) Capers Jones

Capers Jones pixEven after more than 60 years software engineering is not yet a certified profession with licenses, board specialties, and malpractice monitoring as occurs with medicine and law.  While there have been some improvements in programming languages, requirements, design, and development methods there is still need for much more progress.

So long as software applications are based on custom designs and hand coding of applications on a line-by-line basis software cannot really be a true engineering field.  Worse, it will remain one of the most labor-intensive occupations in human history.

Currently software is built more or less like a formula 1 race car or an America’s Cup yacht.  Skilled designers create custom designs which are then manually constructed by skilled programming craftsmen.

Consider the labor content of a formula 1 car compared to an automobile such as a Ford or Lexus that is built on an assembly line using standard components and robotic devices.  An ordinary car constructed on an assembly line from standard parts uses about 30 hours of direct labor.  A hand-built formula 1 car that may need precision machining and custom-made parts can take 3,000 hours of direct labor.

An application of 10,000 logical code statements that is hand coded at a rate of about 10 lines of code per hour will take about 1,000 hours.  By contrast the same application constructed from a set of 100 standard and certified reusable modules could be put together in about 8 hours.

A fundamental question for the software engineering community that hopefully will be solved before 2019 is what are the enabling technologies to move software from laborious custom designs and hand coding to reusable designs and certified reusable modules?

There are bold claims from various methodologies such as Agile that they make marked improvements in productivity and quality.  But so long as software needs custom design and hand coding, it is intrinsically inefficient no matter what methodology is used.

Among the enabling technologies needed to move from manual construction and hand coding of software to automated robotic assembly of software are: 1) A full, scientific taxonomy of common features that occur in many software applications;  2) Effective methods of certifying reusable components that can guarantee with more than 99% certainty that they are free from overt defects and exploitable security flaws; 3) Methods of software architecture and design based on patterns derived from successful existing software applications (i.e. eliminate custom designs and use proven patterns);  4) Secure repositories of certified materials that can be extracted and reused either for a fee or via an open-source licenses; 5) Reusable ancillary materials such as test suites, user manuals, HELP screens, cost data, and histories of any bug reports against the reusable modules.

Instead of lengthy interviews with clients to ascertain requirements followed by custom architecture and design and then hand coding, the author’s vision of future software engineering is as follows.

Requirements begin by meeting with a client and scrolling through libraries of standard design patterns for the application needed by the client.  The design patterns will be derived from successful applications that are already up and running.

Once the basic design is selected, any special features that might require manual customization will be worked out.  But probably these will be rare and if they occur will comprise less than 5% of the total application.

Because the costs and schedule benchmarks for the applications used as patterns are known, it is straight forward to predict the costs and delivery time of the new application.  This would be very similar to buying a new automobile that has optional features.  There are standard price lists for each feature.

Since the designs are accompanied by bills of material, the next step is merely to select the standard reusable components that will be needed to complete the application.  In fact this step could be fully automated:  every design will have a full parts list of standard modules needed.

Assuming that the application is going to be fully constructed from standard pieces, the actual development of the application or connecting the modules could be carried out by robots or some other form of automation.  Human developers might be needed to create the original modules for the first time, but once reuse starts the development effort is trivial and can be fully automatic.

Of course it will be necessary to test the completed application once it is put together.  But since the test cases and test suites are also reusable and included in the parts list, testing too could be carried out by robots or automatic means.

Human software engineers will still be needed to create truly unique applications and to design the reusable modules.  This is the same kind of situation as seen in the circuit design world for building new computer chips and new integrated circuits.  Each reusable software module is similar to a small integrated circuit.

The basic goal of software engineering should be to minimize costly and error-prone human tasks and replace them with automated tasks made possible by combinations of patterns and certified reusable components.

So long as software is custom designed and coded by hand it will always be slow, expensive, risky, and subject to serious security vulnerabilities.  Custom designs and hand coding are intrinsically error-prone and no known method can do anything other than make comparatively small improvements.  To make really big improvements software needs to begin to use proven architecture and design patterns, certified reusable code, and certified ancillary materials such as reusable test cases and reusable user documents.

The software engineering community should also move towards professional licenses and board certification following in the path of medicine and law.  Although it is theoretically possible to achieve these goals by the end of the decade in 2019, it is more likely that they won’t occur for perhaps another 25 years.

Leave a Reply

Your email address will not be published. Required fields are marked *