From the Editor
IEEE Software, January/February 2001
Who Needs Software Engineering?
The traditional distinction between software and hardware was that software
was easily changeable and therefore "soft," whereas hardware was captured on
a physical medium like a chip, was hard to change, and was therefore "hard."
This traditional distinction seems to be breaking down today. Software
delivered via the internet is clearly "soft" in the traditional sense, but
software delivered via CD or DVD is hardly "soft" in the sense of being
"easy to change."
We now commonly see software being delivered on EPROMs; the Electronic
Control Module that controls my car’s fuel injection is an example. I can
take my car to my dealer to have the chip reprogrammed, so in some sense the
program on the chip is soft, but is it software? Should the chip developers
be using software engineering?
Computer chip designers are now doing much of their chip development using
software-engineering-like tools. Only at the last minute is the code
committed to silicon. Do we really think that committing code to a CD ROM
makes it software but committing it to a silicon wafer makes it hardware?
Have we arrived at a point where even computer hardware is really software?
If software and hardware are totally different, then electrical engineers
designing computer chips don’t need to know about software engineering. But
if modern chip design involves a significant amount of programming, then
perhaps electrical engineers should know something about software
engineering. Should computer hardware be designed using software
engineering?
Throw a few other disciplines into the mix such as web programming and
games development, and I think there is a fundamental question lurking here:
What is Software? This question is important because it leads into a second
question, What is software engineering today, and who needs it?
Wolfgang Strigel: There is no doubt that the distinction between
software and hardware has become blurred. When the term software was coined,
there was a clearer distinction, or nobody cared because it sounded good and
made intuitive sense. I don’t think either that it is important that
software is modifiable (or "soft" once it is completed). Software does not
change its nature by being turned into something "hard" or unmodifiable.
After all we have accepted the concept of selling software on CDs. And RAM
can also be write-protected. What matters is whether there is a "program"
that can be executed by a device.
The project plan for building a high-rise is a set of complex instructions,
decision points and so on that could be interpreted as a software program.
But it is not executed by a device. But how about multimedia, say an
animated movie? It has instructions for movement, rendering, etc. and is
executed by a device. It also can be modified. How about a set of MIDI
instructions that produce music if delivered to an electronic instrument?
This is not fundamentally different from a ladder diagram which controls the
execution of a Programmable Logic Controller.
Larry Graham: I agree that the line between software and hardware is
blurry. Patent law has a fairly rich tradition that equates the
two—virtually every hardware device can be described in terms of a function
it performs, and vice versa.
Annie Combelles: I think the basic practices needed to develop software
properly are always the same: get clear and complete requirements from
customers; manage changes to requirements; estimate, plan and track the work
to be done; select an adequate life cycle; define and perform QA activities;
and maintain product integrity. The software architecture and coding might
be different from one application to the other, but the process aspects are
invariant.
Tomoo Matsubara: I don’t think software development is always the same.
My recommendation for improving software process is to apply domain-specific
methodologies and tools and conduct problem focused process improvement. The
levels of importance and priorities are different between domains.
For example, one of most critical process for commercial software is fixing
data flow. For scientific software, a key to success is choosing right
algorithm. For COTS, it’s designing a good man/machine interface. For
embedded systems, it’s pushing instructions into the fewest memory chips.
For maintenance, it’s rigorous testing with regression tests. Software
development practices should vary accordingly.
Grant Rule: Think about the games industry, where the "software" is
delivered on CD ROM or game cartridges. Game development can take vast
amounts of schedule. Teams can be quite large—25-30 people from a variety of
disciplines including analysts, designers, coders, testers, QA staff, and
project management—and lots of non-traditional software personnel such as
writers, artists, and so on. Schedules have to be managed carefully to meet
holiday sales seasons. If a game misses the marketing window and may be a
commercial failure; there’s no second chance. Reliability is important; the
game is mass-produced on CD-ROM, and from that point forward, there is no
real chance to correct it—it is infeasible to recall hundreds of thousands
of copies to fix a defect.
The result seems to be that, in some cases at least, games developers take
a more rigorous approach to "engineering" their software than do some
developers of commercial data processing applications. All this seems to be
"software engineering" to me.
Robert Cochran: I use the following definition to describe what is
unique or special about software:
(1) Software is intangible (which I think is true even if it gets
embedded).
(2) It has high intellectual content (many other intangibles have low
intellectual content).
(3) It is generally not recognized as an asset by accountants and so is off
balance sheet.
(4) Its development process is labor intensive and is team and project
based. We forget sometimes how little of the rest of the world regards
projects as the normal way to work.
(5) Software doesn’t exhibit any real separation between R&D and
production.
(6) Software is potentially infinitely changeable. Once you make a physical
widget, there are severe limits on how you can change it. In principle we
can keep changing software for ever.
Is there any real distinction between printing out a source code listing,
creating a binary, burning software onto a chip or a CD ROM? If all these
cases we are just "fixing" a copy of the software in some form which cannot
directly or easily be modified. That does not have any relevance to the
nature of the software as such.
Grant Rule: That makes software just like any written work or other
art—books, design drawings, and so on. The media/technology may be different
such as wax tablets, canvas, or paper, but anything that can have multiple
copies made in a mutable medium sounds like it "could" be this thing called
"software’.
Martin Fowler: Robert’s Number 5 seems to be the key point. Until you
deploy you can build, modify, and evolve the software, regardless of whether
you eventually deploy to PROMs or CD. That ability to evolve while building
is a key aspect of software that has no equivalent in disciplines where you
must separate design from construction.
This question of how "soft" is software is quite an important point and one
that gels particularly with me. One of the reasons that I’m so much in favor
of light methods is that they try to make software softer while many
methodologies try to make it harder. In the IS world softness is an
important and valuable asset.
Steve McConnell: That does seem to be the age-old challenge—how do you
keep software from becoming brittle? How do you keep it soft? Whether you’re
creating software, or a computer chip, or even a building, it seems as
though it would be advantageous to keep the thing you’re building "soft" as
far as possible into the project.
Terry Bollinger: This overall question helps to deal with trying to
understand the baffling diversity of production styles in the software
marketplace. "Hard" software such as that found in Intel processor chips is
catastrophically expensive to fix after fielding, and so drives the entire
software design process to be very, very conservative and validation
intensive. "Fluid" software that can be changed automatically over the
Internet drives the opposite behavior. I think that understanding these
kinds of issues is quite fundamental to software management.
I do think we need to have a better overall definition of software. The
very fact that I had to mangle together a phrase as awful as "hard" software
to describe algorithms encoded into silicon shows that the industry has
become more complex than it was in the days when you had vacuum tubes and
bits on punched cards, and not much in between.
I think the distinction needs to focus on the idea of "information
machines"—what we have traditionally called software—versus the particular
method of distribution and update of such machines. Those are two separate
dimensions, not one. A bunch of gears is not an information machine, because
it relies primarily on physical materials for its properties, even if it
happens to do a little information processing at the same time (for example,
odometers in cars). A structured algorithm masked into an addressable array
that is an integral part of a processor chip most emphatically is an
information machine, because its complete set of properties can be
represented as structured binary information only, without any reference to
the physical properties of the chip.
Don Bagert: In defining what’s really software, my thought is to look
at what the object code does (rather than where it resides), as well as the
source code. I would define it as follows: "Software is a set of
instructions which are interpreted or executed by a computer." The source
code is definitely "soft" not in the sense of the deployment media but in
that it is a non-physical entity. It consists of a series of instructions,
which are by definition non-physical, which can be translated into object
code or interpreted by a computer processor. My colleague Dan Cooke has an
interesting view: a Turing machine corresponds to computer hardware, while
an individual Turing machine defined to solve a particular problem
corresponds to software.
Steve McConnell: My original focus on the media on which the software
happens to be deployed seems to have been a red herring. I think software
engineering applies broadly to creating complex "instructions," regardless
of the target media. Years ago, people argued that the need for software
engineering had passed because Fortran had been invented. People didn’t have
to write programs anymore—they could just write down formulas! Thirty years
later we now think of Fortran programming as comparatively low level
software engineering—"writing down formulas" is harder than it looks.
As the years go by, we see the same argument repeated time and time again.
The early claims about creating programs using Visual Basic were reminiscent
of the early press on Fortran—"no more writing code—just drag and drop
buttons and dialogs!" And today more new programs are being written in
Visual Basic than any other language. Ten years from now we’ll probably see
programming environments that are much higher level than Visual Basic;
people working in those environments will benefit from software engineering.
Martin Fowler: This is an important point. Often we see people talk
about things "without programming" (one of my alarm bell phrases). You find
this in phrases like, "you buy our ERP system and you can customize it for
your business without programming." So you end up with people who are
experts in customizing XYZ’s ERP system. Are they doing software
engineering? I would say yes, even though their language is putting
configuration information into tables. They still need to know about
debugging and testing.
Indeed whenever we talk about writing tools so that "the users can
configure the software without programming" we run into the same problems.
If you can enter programs through wizards, you still have to be able to
debug and test the results.
Wolfgang Strigel: At the risk of being simplistic I would define
software as follows: "Software is a set of instructions which are
interpreted (or executed) by a computer." I did not say "electronic
computer" since it could well be a chemical computer or one that operates
with light. That delegates the problem to defining the term "computer"—and
that’s a hardware problem!
Editor: Steve McConnell, Construx Software, 14715 Bel-Red
Road, #100, Bellevue, WA 98007.
E-mail: stevemcc@construx.com -
WWW:
http://www.construx.com/stevemcc/
