Four centuries of the Essence of Software Engineering

By Professor Carlos Zapata

 It was the year 2414 and as a newly appointed professor, I was obsessed with history. A few days ago I was working with my obsolete quantum computer, (this model hasn't been produced for the last hundred years ago) to simulate the classical paradox of time traveling. I wanted to experience what my ancestors must have felt when facing such problems. Of course, I don’t need to waste yottaqubits in problems easily solved nowadays with string-theory-based processors, but it’s exciting to spend a little time in this amazing way. However, I realized it was time to get my day started as I recalled I had a scheduled meeting with critical stakeholders today… it’s been a little late now and I was running late.

I jumped in my flying car and quickly set the course to the agreed meeting location, I refreshed in my head the objectives of the meeting and the way I needed to combine the main laws of software engineering in order to address the root cause of my stakeholders current endeavor problem. At that moment I recalled the difficulties my ancestors often faced due to the lack of formalism.

Almost four and a half centuries ago, Brooks’ law was informally expressed as “adding manpower to a late software project makes it later.” I don’t understand how people could have worked with such a lack of formalism. Currently, we cannot live without the revised expression “endeavor time is equal to team size multiplied by work efficiency multiplied by the technological constant.”

However, thinking about what software engineers needed to make this formula, it must have been similar to the age of Physics before Newton and Galileo. The notions of force and speed were very common to people in the 20th century, but a great struggle arose among physicists in reaching agreement on terminology. Of course, my ancestors lived through such a struggle in the early 21st century when Jacobson first proposed the Essence, the main terminology we currently use in software engineering. It is difficult to comprehend how people could have survived without the agreement we now have in the 25th century on basic terms—e.g., stakeholders, requirements, software systems, work, and team.

I can imagine the skeptical voices arguing that Essence was not different from the well-known methods at the time but with a different label. Jacobson was supported by Meyer, a well-known computer scientist, and by Soley, a leader in standard organizations. Jacobson and his team (Spence, Kerr, Ng, Stimson), along with some other thinkers (e.g., McMahon, Goedicke and my ancestor Carlos Zapata) initiated the effort to reaching agreement on the basis of modern software engineering.

Even though the paradox of time traveling is still unsolved, I wish I could create my own time machine and return to 2020 to help these thinkers explain to people why the future desperately needs formalisms and Essence to solve the advanced software engineering problems they will soon face.

Finally, my flying car reached the port of the building. I’ve come to the meeting completely aware that the Essence would help me with the problems of my stakeholder's current endeavor in a similar way that Physics helped so many people after Newton and Galileo. It’s the legacy of software engineering and I want to help raise awareness of this legacy when time machines will be common.