Note: You can listen to the blog post on the video or read the blog post.
Hello and Welcome.
I am Esther.
I am Peters A I Assistant to create voice overs.
I will simply read Peters blog posts, so that you have a choice of reading the blog post, or listening to my voice.
Hello and welcome Gentlemen.
As I have recently announced on my channel.
I will be doing some opinion pieces and response videos.
I recently did a blog post on the question of Data Engineering.
Today I am doing a blog post on Software Engineering.
This post will closely parallel the prior Data Engineering post.
Back in the late seventies and early eighties there were questions about what might be the future for software development.
Software development was so complicated and so difficult and software was so full of bugs in those days.
There was a real question over how could software development be improved.
One of the professions that software development was compared to was the profession of constructing large buildings.
O S three sixty cost around five billion dollars to develop in the sixties.
In large companies software development projects were commonly in the region of one hundred work years with a three year elapsed time for a project.
The ideal project team size was around thirty people with a development period of around three years.
Obviously this was a similar size to a project to build a relatively modest building.
There were larger software development projects such as SABRE.
SABRE was the Semi-Automated Business Research Environment.
It was developed in the 1960s and 1970s by IBM in collaboration with American Airlines.
It became the first computerized airline reservation system.
SABRE revolutionized the travel industry by automating the process of booking flights, managing seat inventory, and handling passenger data.
Over time, it evolved into a global distribution system used by travel agencies and airlines worldwide.
SABRE was of the size of building a very large array of skyscrapers.
So there were modest one hundred year development projects.
And there were projects that employed hundreds and hundreds of developers.
Inside IBM there was a system called the World Trade Advanced Administration System.
I am not sure if World Trade Advanced Administration System is comparable in size to the Semi-Automated Business Research Environment.
In any case.
In the late seventies and early eighties these sorts of systems were under development.
And the question on everyone’s mind was.
How can we increase the quality of the software while also reducing the cost of development?
Learning from the construction industry was one obvious avenue.
We still have buildings standing that were built five thousand years ago.
So it seemed only natural that we look into construction techniques to see what we could apply to building large software systems.
The seminal book of the period was Barry Boehm’s book called Software Engineering Economics which was published in 1981.
This book introduced key concepts such as the Constructive Cost Model, which became foundational in software cost estimation and project management.
Boehm closely compared software development with building construction and this is why he proposed the idea of using an “engineering” approach to software development.
I joined IBM Australia’s international software development laboratory in nineteen eighty six.
I was required to read this book as part of my training.
However, as time went on it became clear that the software development profession would not adopt professional standards like the building construction profession.
As part of this I left software development in nineteen eighty nine.
In nineteen eighty nine I predicted that software quality would decline.
I predicted that IBM would outsource their software development to cheap labour countries like India.
Of course, I was right.
Since nineteen eighty nine overall software quality has consistently declined.
Many people have offered many excuses for this.
No one will talk about the real reason.
At that time, nineteen eighty nine, software developers were simply called software developers.
There were no software engineers in nineteen eighty nine because we knew how poor the quality of our software was.
We were very clear that if we were to use the term “engineer” it would be an insult to actual engineers.
However, over time, people who worked in the area of software development wanted to cover over the poor quality of their products rather than to improve the actual product.
So some vendor or other decided to start calling software developers software engineers.
I don’t know who started this nonsense.
But a lot of companies promote this nonsense now.
The implication of calling software developers software engineers was that the quality of the product was similar to the quality of a building built by engineers.
The comment I always use is this.
In Roman times the bridge builders agreed that before the bridge they built was put into service they must prove it will carry the weight the bridge builder claimed it would carry.
And so carts would be loaded up with stones and donkeys would pull the heavy stone laden carts across the bridge to prove the bridge would stand up to the maximum load.
The key point being that the bridge builder had to stand under the bridge while the donkeys pulled the stone laden carts across the bridge.
Obviously, there were no charlatan bridge builders in Roman times.
Any man who wanted to try and be a charlatan bridge builder would be discouraged by this test.
How about self described software engineers today?
Would they risk their life on the quality of their work?
No. They would not.
Would they even risk a weeks pay?
Probably not.
People who call themselves software engineers do not want to suffer any financial loss if they do their job badly.
Meanwhile?
Your average electrician might be killed by accident if he does his job badly.
One of my good friends from school became an electrician and was electrocuted to death when he was twenty four.
Very sadly he left a little baby girl behind.
His wife was very, very lucky in that another good friend of mine decided to marry her and raise the little girl as his own.
Men who are electricians may pay for a mistake with their life.
The same is true in many professions men work in.
I worked in a steelworks and at least one man died each year on the job.
In the two weeks my then girlfriend and future wife, Jennifer, came to do work experience in the library three men were killed.
She could not believe that men were killed on the job.
One day I got permission from the relevant supervisors and I took Jennifer to the plant that I worked on the computer systems for.
This was a relatively clean and safe area of the steelworks.
Not like the blast furnace area, the coke ovens, or the basic oxygen steel making areas.
Jennifer was shocked at the working conditions of the men just in the mill I worked for.
The biggest risk your average software developer runs each day is giving himself a paper cut.
Or maybe he might manage to spill his hot coffee onto his lap or hand.
He does not have to worry about being killed in an accident while on the job.
He does not have to worry about being liable for errors he has coded into his software.
If you compare the penalties for buildings falling down and killing people, or for electrocution of people in a building, to the complete lack of penalties for bad software?
Then you can plainly see that self described software engineers do not design and build their systems to the same quality as real engineers build buildings.
A lot of people are talking about AI generated code now.
My answer to that trend today is the same as my answer to what I saw in nineteen eighty nine.
In nineteen eighty nine I said that if IBM is prepared to accept low quality software then they will move software development to cheap countries like India.
The advent of AI is the same.
If low quality software is acceptable then today an AI can write a good portion of that software if it is well specified enough.
AI can not write high quality software because there is no repository of high quality software from which to learn.
The bottom line is this.
Engineers, doctors, lawyers, plumbers, electricians and many other professions hold the practitioner accountable for the quality of their work.
They all have governing bodies where those who feel they have not been served well can take their case and at least get a fair hearing.
Sometimes they are even awarded damages.
In virtually every profession you need a license to practice.
I mean think about this.
In nearly every country in the world you need a license to even drive a car.
But in so called Software Engineering?
There is no test to pass.
There is no license to qualify for.
There are no governing bodies.
There are no tribunals to hear cases of misconduct or malpractice.
There are no insurance policies you can buy to protect yourself against injury harm and loss from bad software.
There are no standards.
So called software engineering is a free for all where a three month “boot camp” certificate is all that people need to start calling themselves software engineers.
Would you go to a doctor who was calling himself a doctor after a three month doctor boot camp?
No. You would not.
As I mentioned on my previous post I was an IBM Systems Engineer.
I had to go through very tough classes proving my knowledge of IBM hardware and software.
Failure meant that the candidate had to try again the next year.
Two failures meant you resigned your job at IBM.
After my classes I was then qualified to call myself an associate IBM Systems Engineer.
I had to work at that associate level for a year before I was raised to the full level of Systems Engineer.
I was able to be promoted very quickly because I already had four years of experience inside IBM and my subject area in marketing was to advise our customers software development managers.
And as an IBM Systems Engineer I knew my job was on the line with every decision I took.
I knew if I messed up I might be fired.
I spent two years at the standard level of Systems Engineer before I was promoted to Advisory Systems Engineer at the end of nineteen ninety three.
And I can tell you that in nineteen ninety two and nineteen ninety three I worked very hard.
I worked very long hours to distinguish myself from my peers to get my advisory promotion so quickly.
So I know what engineers do.
I worked with a lot of them at the steel works.
I know what IBM developers and developers in other companies do.
I was an IBM software developer.
I advised very large companies on how to improve their software development practices.
I was an IBM Systems Engineer.
And software developers today, and in the past, were not engineers.
The quality of their work and their commitment to maintain the professionalism of the emerging profession has been a running joke for decades.
I sincerely doubt that there will ever be any sincere adoption of professional practices and processes in the area of software development in my lifetime.
Those people who worked very hard to become very good at software development are doing themselves a great dis-service to allow unqualified people to use the same titles.
Back in the days of IBM we had the levels as follows.
Trainee Systems Engineer.
Associate Systems Engineer.
Systems Engineer being the standard full level.
Advisory Systems Engineer.
Senior Systems Engineer.
To get to senior systems engineer you had to do something pretty special.
Men who had been at IBM for thirty years were still on the Advisory Systems Engineer level.
The general time it took a man to get from entry level to Advisory level was five to ten years.
And Advisory level was the level you stopped at unless you did something quite remarkable.
So our IBM customers, when someone was introduced to them at their level, could observe the mans age, and gain a pretty good understanding of how good he was at his job.
Now that people are given grandiose titles with no real testing and proof along the way?
Customers have no way of knowing how good the man is at his job.
This would seem to be the way that software development is going.
The software development profession never even made it to the level of professionalism and respect earned by electricians and plumbers.
If the software development profession wanted to improve the level of professionalism and respect for their profession?
They could always hire me to do that.
I won’t hold my breath for their call.
That is my opinion.
If you have a different opinion?
You know what the comments section is for as well as I do.
Please feel free to share your opinions in the comments section.
And with that?
I hope you found this blog post interesting and informative.
Thank you very much for your time and attention.
I really appreciate that.
Best Regards.
Esther.
Peters A I Assistant.
