admin- Posted on
As of 2014, it is estimated that there are over 11 million skilled software developers in the world. One of the greybeards at the first corporation I worked with gave me some advice when I first started as a programmer in 1973. “Learn the things that never change,” he advised.
I began college six years ago, in 1967, at a school that did not have a Computer Science major, so I completed my undergraduate and graduate studies in Mathematics, with a few computer engineering courses thrown in for good measure. In the 1970s, this was how many of us got our start as software developers.
The term Software Engineering was invented at the 1968 NATO Software Engineering Conference, which was the first time it was used. The thought back then was that we wanted to adapt existing engineering approaches to software creation in order to solve the “software crisisbudget, “‘s timeline, and efficiency issues. As a consequence, what most people think of as Software Engineering entails operations that are somewhat similar to civil, mechanical, and electrical engineering.
On the surface, this definition seems to be rational. When using other engineering disciplines to construct something (for example, a bridge, a structure, a specialized piece of hardware, or an electrical circuit board), you must first determine the specifications, then plan, execute, and analyze the solution. Many of these measures are also applicable to software. So, from this viewpoint, software engineering may be seen to be similar to these other engineering disciplines. This comparison easily falls apart as you consider what we’ve discovered about software development over the past four decades, as well as how we teach it to today’s software developers.
Since computer programming had become such an important aspect of what was then known as Computer Science by the 1990s, many universities had included a course called “Software Engineering” to their Computer Science curriculum. Ian Sommerville’s textbook “Software Engineering” was one of the most common textbooks used to teach these courses at the time. I taught Software Engineering at Binghamton University from 1992 to 1994 using the Fourth Edition of this textbook. Ian Sommerville’s textbook, currently in its Ninth Edition, is still in use in many universities around the world. This raises the following question:
Why do we need to rewrite a textbook that is meant to teach our students the basics of software engineering every 3-4 years?
The vast majority of textbooks used in Civil Engineering, Mechanical Engineering, and Electrical Engineering do not require revisions almost as often. To explain why this is the case, we need to take a closer look at what is learned as “Software Engineering” in most universities around the world.
When you do look more closely you will find that we are teaching our next generation of software professionals whatever is currently popular in terms of software practices, and methods. Popular software practices and methods today are known by buzzwords such as Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP and the list goes on and on…
When you look closer, you’ll see that we’re teaching whatever is actually common in terms of computing practices and approaches to our next generation of software professionals. Buzzwords like Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP, and the list goes on and on today are used to describe common software processes and approaches.
The issue with this approach to teaching Software Engineering is that software practices and approaches come and go constantly, and will continue to do so in the future, necessitating Sommerville’s constant updating of his textbook. This raises a new question:
et’s take a step back and ask a couple separate questions before answering these:
Is there a collection of topics in Software Engineering that never change?
Do we know what they are if they exist?
If we know what they are, are we teaching them to our next generation of tech professionals in a clear manner so that when they graduate from university, they are ready to conduct themselves as software professionals?
There is such a thing as a compilation of information engineering fundamentals. This conviction has prompted a multinational community of volunteers to undertake the challenge of codifying such necessities. The goal is to teach these fundamentals to our next generation of software developers, preparing them to be true software professionals.
Since 2010, the volunteers who are part of this project (known as SEMAT – Software Engineering Method and Theory) have been working on it. The Object Management Group, an international standards consortium, announced this year that “Essence” has been adopted as an official OMG standard, marking a significant achievement for SEMAT.
As a result, I have a couple more questions:
How does the Essence norm vary from what our software engineers are taught now, and what has been taught over the past 40 years in the name of Software Engineering?
Moreover:
Will the gaps actually deal with the issues that many people think already afflict the tech industry, such as budget and scheduling overruns, and low software quality?
From one perspective what Essence captures is not new. The Essence standard includes common words such as, Stakeholders, Opportunity, Requirements, Software System, Team, Work, and Way of Working. But from another perspective what Essence captures is dramatically new. In fact, some are calling it a “paradigm shift” that many of the “old guard” will have great difficulty even comprehending.
What Essence captures, in one sense, is not new. Stakeholders, Opportunity, Requirements, Software System, Team, Work, and Way of Working are all included in the Essence standard. However, from a different viewpoint, what Essence captures is completely new. Indeed, others are referring to it as a “paradigm change,” something many of the “old guard” would find difficult to grasp.
I recall one specific project I worked on and a customer pilot instructor I worked with. After explaining to him how he could use my record/playback software to help him demonstrate to his student pilots where they had made mistakes, he excitedly wrote up a number of defects requesting changes to my software.
I pleaded with my software manager vehemently that none of these questions were flaws. The pilot teacher started to envision new capabilities that could make his job simpler after I took the time to demonstrate what was possible with my record/playback program. And if they were all upgraded features we never planned to produce and were not part of the specification, he wrote them down on a defect form.
My project manager, on the other hand, refused to negotiate with the client whether these demands were in-scope or not. His viewpoint was that it was better to modify software than to include the user in a conversation, as many others did at the time and still do today.
We like to think of software as being easy to modify because it is soft. It’s not the same as hardware. Metal is difficult to bend. When it comes to tech, this viewpoint changes everything.
The ability to update software code easily and in an infinite number of ways totally alters the relationship between software engineers and their clients, such as program managers and consumers. When customers get more acquainted with the program, they often find different ways that updates to the software could make their job simpler, as my pilot instructor customer did back in the late 1970s.
The ability to update software code easily and in an infinite number of ways totally alters the relationship between software engineers and their clients, such as program managers and consumers. When customers get more acquainted with the program, they often find different ways that updates to the software could make their job simpler, as my pilot instructor customer did back in the late 1970s.
We now know from our own perspectives that there are other aspects of Software Engineering that are important to advanced software engineering activities. This additional measurements go beyond the ease at which the code can be modified. These additional measurements have gained even less consideration than they deserve to date.
When you change code, you can impact the specifications as well as other functionality in the software system that were previously checked. Changing code necessitates extra effort, checking, and likely revisions to supporting user manuals, among other things… All of which has an effect on the budget and timeline, as well as adding to the likelihood of software quality.
While the software engineering community has learned a lot from other engineering fields, they’ve also realized how important these other aspects are in terms of bringing new perspectives to past engineering experiences. Because of these discrepancies, software developers must be qualified in new and unique ways in order to be successful software practitioners.
While the software engineering community has learned a lot from other engineering fields, they’ve also realized how important these other aspects are in terms of bringing new perspectives to past engineering experiences. Because of these discrepancies, software developers must be qualified in new and unique ways in order to be successful software practitioners.
One of SEMAT’s founding signatories sent me a draft copy of a book he was working on to review shortly after the initiative’s launch in March 2010. Watts Humphrey, who had intended to be very involved in the early SEMAT work, became ill just as the SEMAT work was ramping up, and I was asked to assist him in launching his planned effort. Watts sent me the following email in late August of that year, just a few months before his death. He decided to let me forward this email to others:
When they do, their graduates will be able to bargain with their bosses and perform more jobs…. That is just what professionals can do… Convincing them of the importance of making tech people calculate their own job would be a positive step in this direction. Since software development is, as previously said, a knowledge-based discipline, all truly precise measurements must be made by the software professionals themselves. Humphrey Watts
The father of software efficiency, Watts Humphrey, has been dubbed “Watts Humphrey.” After a distinguished career at IBM, he went on to found the Software Process Program as a fellow of the Software Engineering Institute. He received the National Medal of Technology in 2003.
Watts may have been encouraged by the SEMAT work that is currently being done in academia. Dr. Carlos Zapata at the Universidad Nacional de Columbia in Medellin, Columbia, has created and is delivering the first full University course based on the current Essence standard this year, and Essence is being used in first- and second-year digital engineering courses at KTH Royal Institute of Technology in Sweden under the guidance of Dr. Mira Kajko-Mattson.Dr. Cecile Peraire of Carnegie-Mellon West in the United States has also completed Essence field experiments with students. The SEMAT community’s next step is to show how Essence will aid in industry by publishing case studies of real-world evidence from industrial ventures.