|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Software Engineering is Not Computer Science
"A
scientist builds in order to learn; When
interviewing candidates for programming jobs, one of my favorite interview
questions is, "How would you describe your approach to software
development?" I give them examples such as carpenter, fire fighter,
architect, artist, author, explorer, scientist, and archeologist,
and I invite them to come up with their own answers. Some candidates
try to second-guess what I want to hear; they usually tell me they
see themselves as "scientists." Hot-shot coders tell me
they see themselves as commandos or swat-team members. My favorite
answer came from a candidate who said, "During software design,
I'm an architect. When I'm designing the user interface, I'm an artist.
During construction, I'm a craftsman. And during unit testing, I'm
one mean son of a bitch!" I like to pose this question because it gets at a fundamental issue in our field: what is the best way to think of software development? Is it science? Is it art? Is it craft? Is it something else entirely? "Is"
vs. "Should" We have a long tradition in the software field of debating whether software development is art or science. Thirty years ago, Donald Knuth began writing a seven-volume series, The Art of Computer Programming. The first three volumes stand at 2,200 pages, suggesting the full seven might amount to more than 5,000 pages. If that's what the art of computer programming looks like, I'm not sure I want to see the science! People
who advocate programming as art point to the aesthetic aspects of
software development and argue that science does not allow for such
inspiration and creative freedom. People who advocate programming
as science point to the high error rates of many programs and argue
that such low reliability is intolerable-creative freedom be damned.
Both these views are incomplete and both ask the wrong question. Software
development is art. It is science. It is craft, archeology, fire fighting,
sociology, and a host of other pursuits. It is amateurish in some
quarters, quasi-professional in others. It is as many different things
as there are different people programming. So the proper question
is not "What is software development currently?" but rather
"What should professional software development be?" In my
opinion, the answer to that question is clear: professional software
development should be engineering. Is it? No. But should it be? Unquestionably,
yes. Engineering
vs. Science With only about 40 percent of software developers holding computer science degrees and practically none holding degrees in software engineering, we shouldn't be surprised to find people confused about the difference between software engineering and computer science. The distinction between science and engineering in software is the same as the distinction in any other field. Scientists learn what is true, how to test hypotheses, and how to extend knowledge in their fields. Engineers learn what is true, what is useful, and how to apply well-understood knowledge to solve practical problems. Scientists must keep up to date with the latest research. Engineers must be familiar with knowledge that has already proved to be reliable and effective. If you are doing science, you can afford to be narrow and specialized. If you are doing engineering, you need a broad understanding of all the factors that affect the product you are designing. Scientists don't have to be licensed because they are chiefly accountable to other scientists. Engineers do have to be licensed because they are chiefly accountable to the public. An undergraduate science education prepares students to continue their studies. An undergraduate engineering education prepares students to enter the workforce immediately after completing their studies. Universities award computer science degrees, and they normally expect their computer science students to obtain software development jobs in which they will immediately begin solving real-world problems. Only a small fraction of computer science undergraduates go on to graduate school or research environments in which they are advancing the state of knowledge about software or computers. This
puts computer science students into a technological no-man's land.
They are called scientists, but they are performing job functions
that are traditionally performed by engineers without the benefit
of engineering training. The effect is roughly the same as it would
be if you assigned a physics PhD the task of designing electrical
equipment for commercial sale. The physicist might understand the
electrical principles better than the engineers he was working with,
but his experience in building equipment is in creating prototypes
that are used to advance the state of knowledge in a laboratory. He
does not have experience or training in designing rugged, economical
equipment that provides practical solutions in real-world settings.
We would expect the equipment designed by the physics PhD to work
but perhaps to lack some of the robustness that would make it usable
or safe outside a laboratory. Or the equipment might use materials
in a way that is acceptable for a single prototype but extravagantly
wasteful when units are manufactured by the thousands. Situations
resembling this simple physics example occur literally thousands of
times each year in software. When workers educated as computer scientists
begin working on production systems, they often design and build software
that is too frail for production use or that is unsafe. They focus
narrowly and deeply on minor considerations to the exclusion of other
considerations that are more important. They might spend two days
hand-tuning a sorting algorithm instead of two hours using a code
library or copying a suitable algorithm from a book. The typical computer
science graduate usually needs several years of on-the-job training
to accumulate enough practical knowledge to build minimally satisfactory
production software without supervision. Without appropriate formal
education, some software developers work their entire careers without
acquiring this knowledge. The lack of professional development isn't solely the software developer's failure. The software world has become a victim of its own success. The software job market has been growing faster than the educational infrastructure that's needed to support it, and so more than half the people holding software development jobs have been educated in subjects other than software. Employers can't require these software retreads to obtain the equivalent of an undergraduate engineering degree in their off hours. Even if they could, most of the courses available are in computer science, not software engineering. The educational infrastructure has fallen behind the industry's needs. ________________________________________________________ |
|
|
Features
Engineering
vs. Science 