I started my career as a Software Engineer, writing Fortran 77 signal processing algorithms to find and track missile launchers in the middle eastern desert. This skill was an extension of the signal processing work I did as a grad student looking for information in the data stream of a particle accelerator. The design of the code was straight forward. It was mathematically based, converting equations in books to Fortran using pre-written parts from the IBM Scientific Subroutine Package. This programming was done on a variety of machines from the Xerox Sigma 7, Digital PDP-10, PDP-8, PDP-11, and my favorite the PDP-15. The PDP-15 was a machine that ran Fortran but also Focal, a language suitable for formula calculations needed for signal processing.
Signal processing is a domain of software development well suited to the paradigm of engineered systems. In today's world, hardware and packaged solutions have replaced the 10's of 1,000's of punch cards needed to process signals. Matlab is one example.
This early work took me into other fields of engineered systems. Process control, emergency shutdown, flight avionics, and other embedded real-time systems, including transaction processing business systems. These systems were designed and built incrementally and iteratively decades before Agile was even a thought for the authors of the Agile Manifesto. These systems are complex, evolving, very touchy, required exhaustive testing - even to the point of full proofs of correctness for the code. An empirical proof of effectiveness is, of course, a test suite. But there are software systems where testing is necessary but not sufficient.
There was even an effort at one time to have a system that translated formal specifications into code - skipping the coding part. This domain has turned into the Software Intensive System of Systems (SISoS) paradigm that dominates software development activities today. The link to SISoS has briefing materials on the background and framework shows, software has become a key feature of a rapidly growing range of products and services from all sectors of economic activity. Software-intensive systems include:
- large-scale heterogeneous systems,
- embedded systems for automotive applications, telecommunications, wireless ad hoc systems,
- business applications with an emphasis on web services etc.
Our daily lives depend on complex software-intensive systems, from banking to communications to transportation to medicine.
And of course estimating the effort and duration of SISoS is a critical success factor for any business providing products and services to this domain.
So when would a software system NOT be Engineered to fit the Needs of the Customer?
Good question. I guess when the software is created straight out of the mind of the developer with no thought to the consequences of each decision made during the development.
In our current SISoS world we call this a Unicorn Solution.
It's perfect, no need to consider risk, uncertainties, analysis of alternatives, performance and effectiveness measures of the design, the resulting code, the maintenance and operations of that code, or even estimate what the Unicorn solution will cost when it's done, or even when it's done, because deadlines in the Unicorn world are evil and impact the self-esteem of the developers. I have the ceramic Unicorn on my desk and we take it out and put it on the conference room table, along with the
I have the ceramic Unicorn on my desk and we take it out and put it on the conference room table, along with the Dead Horse on a Stick to remind ourselves we're headed for the ditch when the discussion loses touch with the reality of writing software using someone else's money - usually a lot of money.
The answer to the question above seems to be ...
Only when the value at risk is de minimis can we spend other people's money writing software and producing business or technical value from the money without engineering the solution to fit the needed capabilities, for the needed budget, on the needed date to start producing value.
All other activities need some form of thought process built around assessing the outcome of our decisions in the presence of uncertainty, and that of course requires we make estimates of the impacts of those decisions.
This is called engineering the solution. And engineering is defined as the application of mathematics and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes, solutions, and organizations.
So if you're writing software and NOT doing the things in the list above, I guess you're creating an art form or are a craftsman, not a software engineer.
