According to some [Keyes92] "The software development process is broken". Others disagree(see below). In this chapter I explain why we need to study current ways of producing software before trying to fix them.
I show that what is being done and what is taught is not engineering: Engineering has a wider scope and uses formal and graphic methods.
The main argument in this chapter is as follows:
I also show that it will benefit all computer professionals if we separate the engineering of software from the science of computing. We can then start to reconstruct software development using computer science as a basis and practical experience as a guide.
In January 1990 and Summer 1991 programming errors disrupted millions of telephone calls. The software was produced by a different telecommunications company to Olsen's but one with a similar "quickly to market" philosophy. In April 1993 John Bischoff, the vice president of this company described how this failure forced them to make fewer mistakes. By using techniques mentioned later and by changing the company culture from "quickly to market" to "quality first" their backlog of problems and their problem report rate were reduced by two- thirds. [ Footnote 1 ] This shows that one can also change software production to emphasize reliability rather than time-to-market.
You don't need a disaster to attempt to do software differently! But first you must admit that you have a problem:
Fate proved otherwise. [...]development was canceled due to customer rejection." [AllenCD95] (p83)
A third example of organizational turn-round is the shift in focus from technical skills to real customer needs inside WordPerfect Corporation in the early 1990's. [AllenCD95] This example is interesting because the company was not in crisis, and the change was started from below:
A fourth example of getting a software process under control is the NASA/IBM Shuttle Software Project 1970-1990. [MaddenRhone84] [SpectorGifford84] [Billingsetal94] This used IBM's Cleanroom method. It has been used, 1987- 1993, in seventeen industrial size projects with documented savings. [Hausleretal94] Once under control the process was improved. The Software Engineering Institute's Capability Maturity Model codifies this idea[See MATURITY in my bibliography].
In all cases so far described the organization had to (1) recognize a symptom of a problem and then (2) diagnose it, (3) work out a plan to solve the problem. Diagnosing problems and making plans is a part of systems analysis.
Therefore we need to become more skillful at analyzing software processes. This monograph analyzes a large number of practical and theoretical processes in the hope of (1) developing some idea of the problems to expect given a particular kind of process, and (2) to develop a set of sub-processes that can be used to fix diagnosed problems.
Even when all is going well it can be standard operating procedure to continually review the way things are done in an organization. This can be via a complex process like the above IBM Cleanroom approach, by Basili's Experience Factory [Basili95] , or something as simple as preparing a postmortem analysis (also known as a post-delivery review or a post implementation audit) of all completed projects. [BradyDeMarco94] [Glass95] By extracting the "Best of Practice" later projects can be improved. [Glass94] [Glass95] Listing the things that were done wrong can make a postmortem document both well read and useful. [BradyDeMarco94] This fits nicely with Hoare's experiences(above). It also fits the final conclusion by Akira K Onoma & Tsuneo Yamaura based on work at Hitachi: "We learn some things from success, but a lot more from failure"(page 76 of [OnomaYamamura95] ). Hitachi use a traditional sequence of analysis, design, code, and test. By applying industrial quality control models to software testing and debugging they reduced the number of faults found at customer sites from over 1000 in 1981 to less than 20 in 1994. They stress the need for measurement, estimation, and planning plus a separate quality control team. They have a refreshing piece of advice that might account for the reduction of customer discovered errors:
So, it looks as if organizations producing software can change for the better - tho' different organizations may have different ideas about what is better! Individuals can also improve themselves - by using a similar process: monitor, record, analyze, try out, change,... . Watts Humphreys has formulated a Personal Software Process(PSP) that lets individuals and small groups
2.2 "Look what we've done!"
Software professionals have developed a new technology that includes development and personal productivity tools,
Graphics, Data Base Management Systems and end user programming systems. Multi-user, multi-processor, and
multi-programming systems are in wide use and connected together by local and wide area networks. We have many
tools and techniques including: Compiler-compilers and lexical analyzers, generic operating systems and
environments, shells, editors, CASE(=Computer Aided Software Engineering), prototyping systems, Object
Oriented Programming Systems, Expert Systems, and Logic Programming. As De Grace & Stahl put it:
2.3 "We're OK"
Research
[AlaviWetherbe91]
confirms anecdotal evidence[letters to the IEEE Software magazine and Usenet
Newsgroups 1993-94] that some people are happier with their own way of doing things. Others claim a right to
practice their mastery using by intelligence and inspiration.
[Gelernter91]
[Gelernter93]
James Bach describes this
philosophy as:
However, by the end of the 1990's, the above movement towards process ran into a counter-reformation under the banner of AGILE software development. Some forms of agile develop seem to depend on inspiring a heroic response to an impossible situation, [Highsmith99] for example.
UNIX resulted from such heroism (See Ritchie & Thompson's Turing Prize lectures, also [Garncarz94] ). UNIX is, as a result, powerful, and quirky. It has many bugs and loopholes. [GarfinkelWeiseStrassman94] So, in 1989, a tape worm got loose on the Internet and slowed or stopped hundreds of computers. It exploited both accidental defects and deliberate loopholes in UNIX which had been knowingly left active. [McIlroy90] A recent set of tests showed that about a quarter of the UNIX utilities have avoidable catastrophic faults. [MillerFredricksenSo90] Similar problems are present in UNIX's rivals ( for example [Landwehretal94]) as well.
Such results have been predicted [Martin85] [Gerlernter89] for this way of developing software. Worse, similar processes can lead to vaporware projects that can last decades - for example Ted Nelson's Xanadu system - or cost hundreds of millions of dollars - for example [Oz94] the CONFIRM hotel reservation system.
Some organizations are only paying lip service to improving their methods while their practice is still a matter of quick bug fixes. [Hsia93] It is tempting for management to ignore problems or cover up problems [Oz94] Sheila Brady (a successful software manager) calls this denial. She has discussed with Tom DeMarco how and why it can occur. [BradyDeMarco94]
Kraut & Streeter's study of software work in one large company suggest that senior software management's judgments of projects and products tend to be unrelated to the client's opinions. [KrautStreeter95]
Robert Glass blames researchers and vendors for creating a "software crisis" to win funds for research or a market for a products. [Glass94b] Others blame the media for sensationalizing failures involving software [ comp.software-eng on Usenet, also [Glass95]
2.4 "We have a Problem"
However: much of the software I and others use, administer, and maintain is
too imperfect for me to think that there is no room for progress, or that
we should sit back and suffer.
[Agre95]
I am not alone. The $125 million canceled CONFIRM project [Oz94] is evidence that the state of the art may not be a rosy as Glass thinks. There is independent evidence that software is less reliable than hardware:- fault tolerant Tandem systems in one period reported 200 problems but more than 70% were definitively software faults while only 13% where definitely not software. [LeeIyer95] Similarly Windows NT was delivered 18 months late, and the features of Windows 95 were once promised for delivery in 1993 [Schindler95] Richard Adhikari quotes a poll by the Software Productivity Group in 1994 of MIS things-to-do lists. The following are listed by more than 50% of those surveyed:
Robert Glass claims [in Glass 94b and 95] that there is no `software crisis` but a "research crisis". He suggests that the first step to resolve it is for software practitioners to get back their self-belief. However I have seen little evidence (on the USENET newsgroup comp.software-eng, the IEEE and ACM magazines and journals, or the trade papers) that practitioners are any less "can-do" than before. One of the distinguishing features of computer programmers is that they believe that they can solve problems by writing programs. They believe that it is their personal knowledge, skill, and creativity(heroism) can overcome any problem. It is a rare programmer that will admit that the "Best of Practice" is anything other than what they do already. As Leveson & Turner put it in their analysis of the Therac-25 accidents(1985- 1987):
Programming and self-belief are the only things that Microsoft(MS) seems to believe in. In MS, management is seen as a source of bugs slow down the rate at which programmers can produce and test code. [Zachary93] [Pascal94] [CusumanoSelby95] [Keuffel95b] The self-belief of practitioners is confirmed by a project carried out on the Internet by Ted Lewis that indicated that people in the software industry expect a revolutionary improvement in their abilities despite contrary opinions from researchers. [Lewis95]
Now, Glass suggests that self-belief leads "some programmers to disdain research, as the more radical programmers argue that the researchers[...] are not worth listening to". [Glass95] He places this observation in 2020 but I heard it every week on Usenet in the 1980s and 1990s. Glass finishes his article: "a marriage of theory and practice was the surest way forward for the software industry". He does not mention any of the existing work that has been done by researchers and practitioners working together. Neither does he note that most respected researchers - Hoare, Dijkstra, Parnas, etc. - were all been practitioners before they were researchers.
From the research side, David Lorge Parnas claims that even the most influential papers in the first seven International Conferences on Software Engineering have had no effect on practitioners. [Parnas95]
The intent of this monograph is to report on and compare theoretical and practical ways for producing software and extract the "Best of Both." I don't promise a "One size fits all" method. There are too many different types of environment for software people for that! [Bond95] It will be an improvement if we know how to match ideas to situations. For example: We have a well known procedure for producing compilers for programming languages. It would be good to have more statements of the same form: "The best way to procedure for producing an XYZ for ABC is ...." [GlassVessey95] [Jackson94]
2.5 The Software Traffic Jam
As in Hoare's time, as in the Shuttle project in the 70's, and as with
Word Perfect in the early 90's, much software is stuck in a rush hour
"traffic jam". Problems are hitting the producers faster than they can
service them
[Olsen93]
[Olsen94]
[Billingsetal94]
For example, according to Larry O'Brian a burst of late changes contributed to the Denver International Airport fiasco of 1994 [OBrian94] A reliable process needs to lower the rate that mid-project changes are perturb the process and/or raise the rate of handling them as they occur.
One large customer (the USA Federal Government) published a report that certain software projects costed too much and were either late or never delivered. However these were the worst projects. The percentage of troubled software is not published. [Glass94b] But my experience is that when software is delivered on time and within budget then it needs fixing (cf [Chapman90] and page 90 column 2 of [OsterweilClarke92] ). One operating system I administered in the late 1990s is delivered on a CDROM plus an additional CDROM full of fixes. Once installed and working, new defects appear and new features have to be added. Something similar happens with the system on three different laptops and an iMac I've used since. [CollofelloBuck87] After buying schedulers that failed, CASE tools with bad performance, and compilers that crashed, one manager asked: "So, what do our customers think of us?" [Christensen94] This question (among others) is a key part of SQA(=Software Quality Assurance), see box in section 3 below.
All software is changed [Brittan80] , pp128-129 of [Dasgupta91] , p268 of [PlaiceWadge93] , page 95 of [Pierce93] and [Billingsetal94] Even on the Voyager probe about to leave the solar system! Often an apparently good program costs more to change than it should. [Genuchten91] So, badly done software means lost time and wasted effort. [Collinsetal94]
Inexpensive hardware let more people use computers, so bugs are now everybody's problem [CSTB89] [BerzinsLuqi91] [LittlewoodStrigini92] [Matsumoto95] Much software is now too important to be improvised . [Lawson90] [Nissenbaum94] Bugs are becoming a matter of life and death:
The worst Allied casualties in the 1991 Gulf War could have been avoided if
a small and known bug had been fixed.
[LittlewoodStrigini92]
2.6 Summary
Software development does have problems, but they can be fixed. The next
question is: How?
. . . . . . . . . ( end of section 2. The State of Computing) <<Contents | End>>
3. Silver Bullets
Brookes did not write about changes in the way we think and organize things. He did not analyze the convergence of methods and techniques illustrated by recent research, for instance: [HigaMorrisonetal92]
Alan Davis's "Lemming Trails" (page 81 of [Davis93] ) are fads and fashions that they can only make a small improvements but can be disastrous ["Lemmingineering" in the IEEE Software Magazine V10n5(Sep 93)]. DeGrace & Stahl [DeGraceStahl9] refer to "Tool of the Week" and "Method of the Month". Parnas complains:
Warren Keuffel notes how CASE was hyped as a "silver bullet" but turned out to be "a technology in search of an application". [Keuffel95a] Robert Glass castigates the marketing of untested methods under the banner of scientific research(cf [Fenton94] [Fentonetal94] [Glass94b] [Glass95] ):
"[..]t he first step is not to by a C++ compiler or any other object-oriented language. If you are going to enter a rider into the multi-kilometer Tour de France bicycle race, you first need to make sure he is fit. " [Racko95d]
"It was concluded that current CASE tools are ineffective because they treat the processes modeled in a naive and incomplete fashion."page 99 of [Krasneretal92]
"Organizations treat reuse as a technology-acquisition problem instead of a technology-transition problem. [...] organizations fail to approach reuse as a business strategy." page 114 of [CardConnor94]
3.2 More Method!
The academic response to a problem is to work on the theory and ignore the practice - Robert Glass has pointed out
why this happens
[Glass94a]
[Glass94b].
He notes (repeatedly) that much published research ignores the current
software engineering system. According to Ruben Hersh this is similar to the development of the philosophy of
science and the philosophy of mathematics: the theory is developed while ignoring what the scientists and
mathematician were actually doing!
[Hersh95].
To get better software engineering we must understand the current system better before rushing in with another quick theoretical or computerized patch [Botting89b] [EnrightWilkens93] [Chusho93] [BradacPerryVotta94] [Bandinelietal95] [Leveson94](pages 69-70). In 1994 Alan Davis proposed two strategies for managers: (1) Get The Big Picture, and (2) Take the Path Less Traveled [Davis94]. The less traveled paths are proven to make small improvements with little risk and cost:
3.3 Formal Methods
(formal): meaning
Net
DeGrace, for example, gives the name "formal method" to any combination of structured methods and a linear "waterfall" process [DeGraceStahl90]. Many programmers a "formal process" is seen as any attempt to "tell the programmer what to do" and so a threat to individual artistic license. There is no knowledge of the creative possibillities of true mathemtical thinking.
I will use the phrases "documented process" or "formal process" to indicate a process that is expected to follow some plan or system that is on record. A "formal method" is a method that explicitly applies mathematical formulae and methods. Such methods can be done with any degree of rigor. I think of this a a scale from elementary, through high, BA, BS and MS level. Our discipline needs us to mix formally presented of ideas with a creative spirit. Professional mathematicians work like this.
So from this position, a formal method can be used inside an undocumented process. Further a rigorously documented process(the typical accredited CS BS degree for example) that relies on natural language and so is informal!
Notice: some formal methods have become part of the best of practice (and so lost the stigma of being a "formal method") and other are in the process of being made practical. Others are ignored. The classic "program proving" methods of the 60's for example are rarely used in practice. On the other hand formal languages like Z, BNF, Ada, C, etc are used in industry.
3.4 Software Quality Assurance
(SQA):
Net
SQA procedures can also ensure that concerns other than correctness are covered - for example security [Baskerville93], safety [Parnasetal90],
But SQA does not replace testing. SQA includes testing. The essence of SQA is to discover defects by examining the products not test runs. The Cleanroom people recommend random tests that reflect the usage statistics in the field since these give a lower final Mean-Time-To-Failure(MTTF) than other tests plus a a better predictor of the MTTF after release [Musa93] [Linger94].
Finally the SQA program must itself be assessed: (1) by seeing how well each step stops defects being passed on, and (2) by recording the reactions of customers to the product. Testing can become a way to assess the effectiveness of the SQA procedures, not an expensive way to find errors.
Finally, even Extreme Programming, has rigorous (if exciting) SQA inside it: Pair Programming means that all code is instantly under review for clarity, correctness, and maintainability. Refactoring plus "Test First" specifications enable a correctly running program to be improved safely to meet other qualities.
. . . . . . . . . ( end of section 3. Silver Bullets) <<Contents | End>>
4. A Profession?
4.1 Introduction
As a start to understanding the problem, consider software professionals.
A mature area will have a complex of overlapping disciplines. They include
managers, scientists, mathematicians, engineers, technicians, educators,
and craftspeople.
Applied mathematics can, without loss of generality, be treated as the overlapping parts of the other disciplines for the moment. Pure mathematics is not intended to be useful but will be examined in section 4.5.3. Consider, in turn, ideal or generic managers, artists, scientists, and engineers. A manager (ideally) works with the people, resources, and goals of a project not the details. Managing a project involves the management of those who research (scientists) and those who design and create (engineers and artists). Management is part of the problem: See [Anon90] [Genuchten91] [Royce92], Piere America's comment in [Lutz93] [Andriole94] [JonesC94] [Oz94].
Management must remove all excuses for failure from the other professionals! They may need to sponsor and support the development of better processes and methods while developing wiser management techniques [Aoyama93] [Olsen93], pages 75-76 [Kanetal94]. Meanwhile they need data - not advertising - on what techniques and technology leading to better software: Compare page 35 of [TichyHabermannPrechelt93]. Hence good management should include testing new ideas before promoting them [Kitchenhametal95]. When new ways are required then they work best when they are owned by those who use them [Billingsetal94]. This is good management technique: Replace control by communication. Compare [BradyDeMarco94] and the recent AGILE revolution.
Hence management can inspire, structure, and encourage experimentation that help select better techniques. A prime mistake however is to treat the development of software making a device on an assembly line (see page 41 of [Raccoon95]). Good design work is not done on an assembly line! We fully automated the assembly of software in the 1950's. It is the design of the assembly that is time consuming.
Design can involve scientists, engineers, and artists. All are creative! They differ in their attitudes and habits. For example an art-object - say, a picture in a gallery - can be useless because its value depends on its uniqueness. Some scientific experiments seem equally useless, but their value is in their reproducibility and the meaning of the results to other scientists. Engineers are dedicated to designing and improving useful objects and systems.
There is an important but often forgotten distinction between artists and the other sub-disciplines. An artist is deeply involved in the production of art objects. However managers, mathematicians, scientists, and engineers do not normally produce anything but bits of paper! It is hard to see, from this point of view what a manager contributes to the profit of a company... it is even harder to see how research and development has any value in the short term. It is vital to realize that engineering and science have long term payoffs rather than producing larger profits immediately. As James Horning points out that if we think that "Widget engineers" make widgets we start to measure their productivity by measuring and counting the widgets [Horning94].
In fact, "bridge engineers" design and supervise others who produce the bridge. Study the Brunels in the UK, the Roeblings in the USA to see examples. This continues in Civil Engineering to this day. This is even more true in a mass market where three or four engineers can spend years designing a single product - and other people actually produce the millions of copies that are sold. Perhaps we should stop confusing the engineering of software with the production of software? Compare [Raccoon95].
Unlike most artists, (but see [ Footnote 3 ] ) the engineer and scientist try to cope with complexity using mathematical techniques to express qand solve problems. Engineers and scientists work with what is and what is believed. Both use an iterative process ending with results that match predictions. A difference between the scientist and the engineer whether they change reality or theory [Dasgupta91] p xvii, p8, pp353ff.... The engineer intervenes in reality using a fixed theory, see p28 of [Potts93], but the scientist modifies the theory to fit observations. The engineer needs reliable established laws [Hoare93] p1 (Introduction), [Glass94b] [Leveson94] pp69-70. But a scientist must probe the unknown by seeking cases that do not fit the accepted theories [Popper57]. So a good scientific experiment is often unthinkable to an engineer( See level 0 in [Wichman92]). Heroic engineering - "going beyond the borders of the known world and returning with new knowledge or wealth" [Bach95] - is not the norm. Everyday engineering is more about the creative application of what is known than the exploring of unknown technology. In fact, engineering failure leads to a scientific breakthrough [Petroski85]. So true scientists seek the unknown, but engineers avoid it.
Further a good piece of engineering can be a bad piece of science. The engineer is happy to of got something that works out of a project and perhaps to have learned about other things that do not work: "...the Darlington experience was not an experiment: we did not gather data or make scientific observations. There was a job to be done as quickly as safety considerations would permit " [Parnasetal94] page 958.
Thus when an engineering team reports that they used a new method or technique and it worked for them then this is a significant piece of data to other engineers. It is not an acceptable scientific result unless the scientific method was followed. To be of scientific value it is necessary to plan at least two different different approaches(treatments) plus carefully measured results and statistical tests [GlassVessey95] [Kitchenhametal95]. However, when two or more projects succeed by inventing a similar technique or method then this may carry considerable weight and inspire other engineers to try the same thing - even in the absence of "real experiments" or a logical theory. It appears that C++, Java, Perl, and other languages were spread by this kind of mimetic process.
As an example - two recent projects failed to use mathematics successfully unless the formula were presented as tables [Levessonetal94] [Parnasetal94]. This does not prove tables superior to formulae. It does not make it more probable that tables are better. It just shows a possible truth. It suggests that it is unduly academic to develop methods that require engineers to not use tables. However it would be an overly scientific engineer who didn't not try out similar notations on similar tasks. But, as C Michael Holloway pointed out, experience can only generate a possible truth, for a probable truth we need experiment, and for truth that is absolutely true in a limited context we need a logical theory. Absolute truth is the gift of the divine. All we get from human authorities is "opinion" [Holloway95]. Or as Watts Humphreys says: "In god we trust, all else bring data!"[PSP courses at CMU SEI 190's].
On the other hand, a piece of research involving careful thought, mathematics, and scholarship, followed up by a set of experiments, and the development of some training programs and university courses may make scientific sense and be ignored by engineers. Here is a recent (randomly chosen) sample:
The problem is that RESOLVE is so complex that it takes many hours of study to grasp it. It also opposes several items of "conventional wisdom". There is no convincing experience suggesting it may improve an engineer's work. So an academic in this situation has a moral dilemma: They have convinced themselves that they have a better mouse-trap, and believe that there is a plague of mice outside their laboratory(indeed they see the mice in their lab equipment!). They have to either (1)let people suffer from mice without the benefit of better mouse traps or (2) they must advertise their mouse traps. These pressures, as well as economics, career, and ego, all tend to encourage the environment of strident advocacy that some complain about[ Holloway, Glass, Fenton, etc].
The time-scales for an engineer and a scientist are different. An engineer expects to develop prototypes on the way to a product - "Plan to throw one away - you will anyway " [Brooks82] compare with [Humphreyetal91] p91, col 3. A scientist is under pressure to "publish or perish." So the kind of experiment that a scientist can finish and publish quickly (a toy(easily described) problem, using students, ...) is not a convincing proof of a method for an engineer [Fentonetal94]. So pure science is most effectively used to produce fundamental results not new products: "the most useful inventions are based on, or improved by, scientific knowledge. Invention produces products, techniques, and tools. Science produces the knowledge and ability to evaluate and improve our products, techniques, and tools. Inventors use science to build better inventions, to know that they are better, and to compare them to what we all ready have." [Leveson94] pp69-70.
Hoare suggests that it costs more to make a product that fails than it does to develop new theories, test them by experiment and peer review, and then develop designs based on these theories [Hoare93] p2. Engineers understand that it is even cheaper to use other people's theories. So, it is to the engineers benefit that he or she does not have to bother with developing the theories that then let them design a good product. Pure or fundamental research is by definition useless! An engineer may be capable of research but tends to feel that it is better done by others.
Scientists also benefit when they are not pressured to produce practical or profitable results. Historically, new theories often come from ignoring profitable practice - for example no 19th century medical doctor would have considered funding the research in physics that lead to a valuable tool of 20th century medicine: X-Rays. Again the most fruitful areas for a scientist to work in are the areas of doubt and uncertainty, the frontiers of knowledge. However these are precisely the areas that a good engineer tries to avoid when trying to find a reliable solution to a client's problem.
Science is evaluated by scientists and practice is developed by engineers. Glass is wrong to imply that bad theories are those that are not immediately profitable [Glass94b]. The pragmatic value of a theory may develop over 5 to 10 years of industrial development[ see time-line from the NRC/CSTB 1995 report, Hamilton 95 page80]. The immediate value is estimated by (1)the scientific method, (2)peer review, and (3)replication of the results by others.
To Summarize:
4.2 Science vs Engineering and This Monograph
In this book I am interested in re-engineering the way we do software,
rather than developing a grand scientific theory: It will be enough to
make some suggestions that have been shown to work and have a theoretical
basis. The evidence comes from many sources and has different values. Some
is "scientific" -- based on theory and experiment in a laboratory. Some is
a report from industry on an experience -- which may or may not be
repeatable elsewhere.
(evidence): sources classified:
SURVEYs compare several different projects, methods, or publications - they can be useful ways to get a picture across many projects but they do not help to establish and rigorous results. POLLS select a collection of people in the field and ask their opinions on a set of questions - these are rather like looking at a weather vain to see which way the wind is blowing. Much published work undergoes private and public REVIEW - where another worker in the same field comments on one or more pieces of work - papers, books, and even pieces of software. A result can also be tagged as THEORY - this means that it is established within a particular logical or mathematical universe. Within that universe's assumptions, it is guaranteed. But there is no evidence for thinking that the result's world is the world in which the engineer is working.
However a good theory is quite useful to good engineers - for example recalling the Venturi Principle of Fluid Flow could have saved MIT repeatedly having to repair the windows in two close by towers when the wind blows. Finally there is ADVERTizing: Here a particular method or technique is described and claims made for it that are not substantiated by either rigorous testing or theorizing.
For example consider Structured Programming. It starts with the proof of the THEORY that GOTO's are not needed to write programs by Boehm & Jaccopini. A new language DEMOnstrates this theory quite well - Algol 60. A letter from Dijkstra publishes some anecdotal (and so weak) EXPERIENCE [Dijkstra68b] that GOTOs make software harder to understand. There is then a slew of THEORY published by computer scientists (hundreds of papers per year at its height) defining what Structured Programming was and what the definition implied. Soon structured programming is adopted by IBM as part of "Imporved Programming Technology" (IPT) and the results are published as an EXPERIENCE [McNurlin77]. There are some EXPERIMENTs published on what structures are best understood - by students [Green80]. Luckily there was not a large market for software tools in those days but even so papers were written purely to ADVERTize some language, method, or tool and provides more rhetoric than usable data. The whole fuss died down with "structured" becoming a buzz-phrase the magic ingredient in anything that was being sold.
Finally "structure" was replaced by "object-oriented" with the whole process was repeated with more ADVERTs. The words "agile", "agent", and "aspect" may follow the cycle in the 2000's.
The sub-disciplines of Management, Mathematics, Art, Science, and Engineering in this subsection(4.1) are developing in the software world. Mathematics and management are well established. Now I look at the Art, Science, and Engineering of software.
4.3 The Art of Programming
See
[ Footnote 5 ]
for the source of this phrase.
People sell software with a disclaimer about its usefulness and value. In the same document they forbid copying [Nissenbaum94] p78. Companies go to court to protect its "Look and Feel" [Gries91]. Therefore their software is an art-object. Worse, it is bad art -- Mody points out that few programmers undergo the rigorous regime of practice, theory, and notation expected of a musician [Mody93]. The typical "Hack first, revise later" programmer is not following the process advocated by real artists eg [Stanley94]. Further recent letters to the Communications of the ACM and on the RISKS Internet Mailing List say " I am convinced that the software crisis is a self-inflicted problem resulting from treating software design as a kind of artistic activity. Unfortunately we do not have enough talented artists. What we really need is to replace pseudo-artists by engineers and to treat programming as a normal branch of engineering." [Wagner90].
" It is my contention that the vast majority of software defects are the product of people who lack understanding of what they are doing. These defects present a risk to the public ..." [Whitehouse91]
A paper on safety critical software makes the same case: "Traditionally, Engineers have approached software if it were an art form. Each programmer has been allowed to have his own style. Criticisms of software structure, clarity, and documentation were dismissed as 'matters of taste.'
"In the past, engineers were rarely asked to examine a software product and certify that it would be trustworthy. Even in systems that were required to be trustworthy and reliable, software was often regarded as an unimportant component, not requiring special examination.
"In recent years, however, manufacturers of a wide variety of equipment have been substituting computers controlled by software for a wide variety of more conventional products. We can no longer treat software as if it were trivial and unimportant.
"In the older areas of engineering, safety critical components are inspected and reviewed to assure the design is consistent with the safety requirements.[...]
"In safety-critical applications we must reject the 'software-as-art-form' approach." [Parnasetal90] p639.
Typically a complex piece of software suffers about two failures for every thousand lines of code per year [PostonandBruen87]. By introducing "sound engineering practices" into the making of an operating system Poston and Bruen claim that they reduced the failures reported by customers down to two(2) during the first year. Linger states that at unit testing, traditional methods encounter 25 to 35 errors per thousand lines of code but in rigorous Cleanroom projects only 2.3 errors are found per thousand lines of code [Linger94]. This improvement is reflected in a low number of errors occurring during use. Similar successes have been reported elsewhere [Endres93]. However current teaching discourages better techniques [Rout92]. Further, students don't want to change from "code & test" [AlaviWetherbe91] p91. Rick Rowe shows that the lack of tools and diagrammatic documentation forces programmers to rely on creativity and visualization [ Footnote 6 ] But we cannot rely on artists alone to produce good software so we must look at the other disciplines: Sections 4.4 and 4.5 look at Science and Engineering as they appear in software projects.
4.4 Computer Science
Juris Hartmanis recently chaired a discussion of computer science
[Hartmanis94b] based on his Turing Prize
Lecture
[Hartmannis95a].
It is clear from this that there are many views as to what Computer science is at the
research level. Hartmannis sees computer science as a new kind of science where crucial tests of laws be experiment
is replaced by crucial new developments being demonstrated. Another author dismisses any choice of "science" vs
"engineering"
[Wulf94].
The following notes are based on observing and contributing to the development of
undergraduate computer science degrees in the late 1980's.
Computer Science is a science of "what can be computed" [Denningetal89a]. It has standardized Bachelors and Masters programs[CSAB]. Computer Science was born from a discipline(mathematics) that was divided into pure and applied camps [Glass94b] [Jackson94]. It has now become a pure science. This is an essential and inevitable development [Hoare93]. Here is a cartoon of how it happened and why it continues: The purer graduates of Computer Science take advanced degrees and doctorates. The doctoral research has little observable effect on the practice of making software. The graduates of doctoral programs become teachers of computer science. So students are taught by people with little or out of date experience and a preference for pure research. The other Computer Science students (those who are weaker or prefer applying their skills) leave the academic world and then learn the methods used outside - be they good or bad. Methods developed for profit, are not respectable topics of research. So there is little or no scientific evaluation them [Glass94a] [Glass94b]. They are not studied by researchers and so are not improved or understood by them. Further they are not taught to Computer Science students. The students graduate believing that such methods either (1) do not exist or (2) are erroneous and so need not be researched or taught. Some computer scientists even re-invent known methods. after [Botting89b], compare with page 11 of CSSyllabus 92, [JonesC95b]
The above positive feedback loop has purified Computer Science. The Computer Science Accreditation Board(CSAB) reinforces this process by specifically requiring that faculty have Ph. D's. in Computer Science. Students of Computing learn to write and debug small structured programs, data structures, operating systems components, and compilers [ Footnote 7 ] They learn to work from specifications and to assess algorithms against them [ACM-IEEECurriculum91] [Poole91]. They have minimal experience of standards, quality control procedures, disciplined design, or other professional techniques of an engineer [Petroski85] [WilliamsD95]. They may not have learned techniques that are missing or optional topics in computer science degrees: such as SQA, Structured Analysis and Design(SAD), Entity-Relationship-Attribute modeling (ERA), or applied mathematics. For years [ Footnote 8 ] practitioners have made comments like: "It's my hypothesis that [Electrical Engineers] write better software than people trained in general computer science. If you are an engineer, your formal education has taught you the process of building. It has instilled you with the need to think about design, structure, documentation and prototype." [Sharon91]
"The 1988 action plan required that [...] software engineers use traditional engineering techniques such as prototypes and experimentation. " [Humphreyetal91], p19
Computer Science is committed to producing Computer Science Ph. Ds. not engineers. Maurice Wilkes says: "I believe I am not alone in thinking that, as an education, computer science by itself fails to bring out the best in people." [Wilkes91]
This may be too broad but Herbert Simon argued, years ago, that it is wrong to teach engineering as a science [Simon69] and Denning has recently argued for a reorganized engineering curriculum [Denning93]. Potts notes that 25 years Computer science research has not changed practice very much [Potts93]. Fenton points out that some computer science theories are rushed into practice without testing as an engineering techniques [Fentonetal94]. Hartmanis stresses the value of demos and the absence of experiments to resolve computer science questions [Hartmanis94a]. The expertise of the scientist and the engineer are different [RoselBailes92], page 61. John Carroll denies the use of science to design software [Carroll91] p 166. So, as Computer Science has become better at producing scientists it became worse at preparing people for a profession of developing good software [Rout92].
An engineer taking a degree in Computer Science notes the lack of Engineering, which he defines by:
"Engineering is a philosophy that transcends professions. It is a systematic, methodical, discipline, deliberate way of approaching a problem. It is not merely a matter of mechanically following an outline of developments phases, dataflow diagrams and so on." [WilliamsD95]
Helen Nissenbaum notes that bugs are so endemic using current methods that accountability is reduced [Nissenbaum94] p77-78. Mary Shaw argues that software engineering is in the same position as civil engineering in the eighteenth century or chemical engineering before 1887 [MyersW90] [ShawM8990]. Leveson demonstrates parallels between steam engineering in the 19th century and software engineering in the 20th century [Leveson94]. A CSTB report proposed steps to develop Software Engineering [CSTB89]. In 1993 the Computer Society of the IEEE started work on "Defining software engineering as a profession" [Buckley93]. Software production cannot be "Software Engineering" unless it includes engineering methods - the IEEE Computer Society's Software Engineering Standards committee is studying another possible redefinition of the area as: "That branch of engineering that is concerned with the development, operation, and maintenance of software." [Buckley93]
I now argue that true Software engineering will need (1) a wider scope than computer science(section 4.5.2), (2) a more formal and scientific basis than the arts(section 4.4.3), and (3) better notations(section 4.5.4).
4.5.2 Scope
The British Computer Society and the Institute of Electrical Engineers state
"SE is not simply a more organized approach to programming"
[BCS/IEE89].
Programming and Computer Science start from a specification as in [Dijkstra89] [Denningetal89b] [ACM/IEEEcurriculum91]. Engineering does not:
Engineering includes understanding an initially unclear situation and selecting the best thing to do [Dasgupta91] [RameshDhar92]. Searching for a solution is only part of engineering. There is more to software as well :
" 'Either I have to learn enough about what the users do to be able to tell them what they want, or they have to learn enough about computers to tell me. ' " [WilliamsBegg93]
"We need to focus[...] on concepts, models, and principles that capture the essence of [the domain...]"p30 [Zave93]
"[...] The prototype is demonstrated to a group of customers. A customer remarks that many terms commonly used in his business are reported as spelling errors[...] The customer does not like this and wants it fixed." [BerzinsLuqiYehudai93]
"The [users] provided an initial description of the new system's intended functions that was, at best, fuzzy. After we translated the requirements into a language the average software engineer could understand, ..." [Staringer94] pp61-62
"For example, a designer of a facility to reply to E-Mail messages begins with an ill-defined, superficial notion of [how to solve problem]. As the design unfolds, the designer's understanding of the problem and potential solutions improves, and he refines and elaborates the problem definition until a satisfactory design emerges." [Henninger94] pp49-50
One computer professional has described three complex but successful software projects and shows that they succeeded because they focussed on a "philosophy" for solving the problem that was independent of the technical aspects of the final solution [Lawson90]. Computer scientists once acknowledged the need for analysis [Strachey66]. Dijkstra described analysis as "the conception stage" in 1968:
" The conception stage took a long time. During that period of time the concepts have been born in terms of which we sketched the system[...]. Furthermore, we learned the art of reasoning by which we could deduce from our requirements the way in which the processes should influence each other [. . .] Finally we learned the art of reasoning by which we could prove[...] " [Dijkstra68c] reprint CACM25 p51, col 1.
Hoare's description of engineering shows that construction is based on designs that should work:
"The next step is, in the light of the objectives and the relative priorities, to choose, or invent if necessary, a solution technique[. . .]
"The consequences of the choice of technique should then be worked out in sufficient detail to be able to predict with reasonable confidence the characteristics of the final product, and it should be determined how well the product will meet its defined objectives. If confidence cannot be established, the previous steps must be repeated, until it is known that the target objectives are at least feasible. [Hoare73]
Similar, according to civil engineer:
"Engineering students are taught not only the principles of engineering, but also the discipline and management to go with it[...] This approach builds in quality control from the beginning so that failure upon completion is almost impossible[...]" [WilliamsD95]
"The first phase culminates in a more-or-less precise specification of the product, which has been agreed with a customer or his representatives." [Hoare73]
Clearly engineering starts long before the product is constructed. So should software engineering.
The methods used in UK Government projects(SSADM and SDM) fit Hoare's description. SSADM(Structured Systems Analysis and Design Methodology) focuses on understanding the situation and making detailed graphical and tabular models that are quantified and proved feasible prior to constructing specifications of the programs[See SSADM in my bibliography]. SDM (Structured Design Method) derives a program structure from describing the specified data. Coding is a separate, often trivial stage[See DDD in my bibliography]. SSADM and SDM need to be studied to see what they can contribute to software engineering.
4.5.3 Mathematics and Software Engineering
According to H Zemanek: "We may not realize, but a blueprint is a formal definition of the object to be produced..."
page 180 of
[ShawB75].
Without science, engineering is a craft:
"Engineers could not exist without mathematics and experimental science. Science deals in pure thought and experimental science is concerned with the laws of nature. In some branches of engineering the dependence is very clear. [...] It has long been accepted that the training of an engineer should include a serious study of mathematics and the relevant science, whatever use he or she may subsequently make of this learning. [...]"
[Wilkes91]
Engineering needs to be based on scientific and mathematical theory(page 35 of [TichyHabermannPrechelt93], [Hoare 93]). Disasters occur when engineers either don't have, forget, or ignore science and mathematics [Petroski85] and [ lookup?from=monograph&search=ENGINEER ] Indeed one definition of software engineering is: "The disciplined application of engineering, scientific, and mathematical principles, methods, and tools to the economical production of quality software" [Humphrey89]. The link between formalism and software is so strong that: "Computer programming has invigorated the study of formal systems, not just because a proper formalization is a prerequisite of any implementation, but because good formalisms can be very effective in understanding and assisting the process of developing programs."
Formulae can be manipulated in a verifiable way:
"Software engineering without mathematical verification is no more than a buzzword." [Millsetal87]
Or as Gries put it: "In Summary, Software engineering, Computing, and Computing education all suffer from a lack of basic mathematical skills that are needed in dealing with algorithmic concepts.[...]Let us all learn more about calculational techniques and gain skill with them[...]." [Gries91]
The IEEE Computer Society appears to concur since in September 1990 they published special issues of "Computer Magazine", "Software Magazine", and "Transactions on Software Engineering" all dedicated to the need and effectiveness of formal [ Footnote 9 ] methods [See FORMAL in my blibiography]. The need for formal methods is especially critical for software engineering. Indeed some computer scientists argues that programs are executable formulae [Dijkstra89]. Formal specifications have contributed to order of magnitude improvements in error rates and doubled productivity [Endres93]. Programming languages try to disguise the mathematical nature of software but are formal languages anyway [Guerevich87]. AI uses logic, Data Base Systems use the theory of relations [Codd],and even fuzzy systems are based on mathematical theories.
In summary, so far: Software Engineers design formal objects to satisfy informal requirements [Wing90a] [BerzinsLuqi91](pages 1..3) [Dasgupta91] [Humphreyetal91] p13. Therefore formality is added in the software process. Where it appears varies from person to person [Lammers86] [Luckhametal91]. Amateurs, artists, users, computer science freshers, and some programmers improvise programs at the keyboard ["hackers" in [Ince88b], "Old man Babbage" at the end of "Goedel Escher Bach" by Hofstadter]. Some use prototype source code as an executable specification for the final product [Hoare87]. Some programmers produce a diagram of the structure of the components of the program, and then translate it, by a series of steps, into code [See Chapter 1 for an analysis of SAD plus bibliography SAD in my bibliography]. Lawson argues that prior to design, a philosophy should be developed from the problem [Lawson90]. Nielsen is blunt "do as much as possible before design is started" [Nielsen92].
Some people start from a formal logical specification [Meyer86] [Dijkstra89] [Luckhametal91] [RomanGambleBall93] p 281. For others the first step is work out a formal specification [Endres93] [KayReed93]. Research is progressing on ways to create formal specifications [Berzins89] [Milietal89] [BerzinsLuqiYehudai93], ... plus search for FORMAL in my bibliography. Abbot suggested using a natural language problem description as the source of information that can be formalized as data types, objects, and procedures [Abbot83]. Others start from an informal description of the problem solution and abstract objects, data, and procedures from this [Booch91] [TsaiWiegertJang92]. Compiler writers, Jackson, Warnier, and Orr start by making a formal description of the data (Data Directed Design [ DDD ]). Related to this are methods that concentrate on Requirements Engineering such as SADT, SREM, SAM* etc. [RzepkaOhno85] [DavisA90] [HsiaDavisKung93]. Object technology has moved from programming, to design, towards requirements, and into analysis [Kramer93] [Embleyetal95].
Dijkstra, Hoare, and many others show that program correctness is always relative to a formal specification. Others are working on deriving the program automatically from a function oriented specification [MorganC90].
"At the heart of the software problem lies a lack of an adequate means to express and manage well-structured specifications, efficient solutions, precise connections between them, and their evolution over time. This problem manifests itself as intellectual unmanageability and, in turn, uneconomical software development and evolution."page 11 of [JŸllig93]
Yet specifications can be less than perfect [Poston85] [Collinsetal94] [KayReed93] p630. They may be ambiguous, incomplete, and over-precise [Schneideretal92]. They may also fail to fit all the "requirements": "In general the quality of a software product cannot exceed the quality of its requirements" [Humphreyetal91]p13 "[...]Formal techniques can be applied to verify whether a specification can be executed in such a manner that the requirements are satisfied." [GabrielianFranklin91] "[...] failure to find a proper abstraction in generating a specification is most often due to a lack of grasp of the requirements, on the part of the specifier than it is to some intrinsic property of the specification[...]" [MiliBoudrigaMili89] p.119
Failing to analyze requirements leads to problems [Golazetal90] [Lindstrom93]. Uncontrolled requirements changes cause errors [Billingsetal94]. Erroneous requirements cause disasters [LemosSauudAnderson92]. "Whenever software considerations were not integrated into system engineering early in the system-definition phase, the software specifications often were ambiguous, inconsistent, untestable, and subject to last minute changes. [...] The 1988 action plan required that software engineers be involved in the systems-engineering process [...] In those cases where software engineers were involved with system design, considerably fewer problems occurred and better products resulted" [Humphreyetal91] p13 and 19.
Requirements are not arbitrary(p 20 of [Wing90a] [BerzinsLuqiYehudai93]. They don't exist in a vacuum [LieteFreeman91] [Chuso93]. "Software development usually begins with an attempt to recognize and understand the user's requirements[...] Software developers are always forced to make assumptions about the user's requirements[...] Often the user has an incomplete understanding[...]" [TsaiWiegertJang92] "Requirements imply something prescriptive. In early modeling, most of what is done is to analyze the problem area, so many pieces of information are more statements than requirements" [LindlandSundreSolvberg94] Beyer & Holtzblatt show that the better software products emerge when the designers are put in direct contact with the customers and each other, rather than with surrogates such as: a "Software Requirements Specification, a manager, or a systems analyst" [BeyerHoltzblatt94] [BeyerHoltzblatt95].
Sometimes the current system is the problem:
"Perhaps the most difficult problem of all is the incoherent, unprincipled, and ad hoc behavior of current [...] systems."p30 of [Zave93].
Software professionals have rediscovered the need to analyze the current system [CurtisKellnerOver92] [Bernstein93]. Systems Analysis evolved from techniques used in World War II in America. The later history has recently been summarized [Keuffel90] [Baskerville93]. It helps bridge the gap between computer expertise and the expert's environment 25 of [MurphyBalke89]. It maps a "Real World Problem" into a "Problem Domain Representation" Figure 1 of [MonarchiPuhr92]. Analysis starts by documenting the current system and searching for problems and opportunities [See SAD and OOA in my bibliography]. Further, as time goes on the current system contains more software. So recent research has looked at the systematic analysis of the current software - under names like reverse engineering, re-engineering, or reuse [ search for REUSE and RE-ENGINEERING in my bibliography]. Tools that help a programmer analyze software are becoming more sophisticated [BrownP91].
Another class of methods start from modeling the world outside the software:- Data Engineering [Shuey86], Logic Programming [SchnuppBernhard87], Dynamic Analysis and Design [Botting89] [Lang93], Essential Analysis and Real Time Structured Design [WardMellor85], Object Oriented Analysis/Design/Programming [HalbertO'Brien87] [Booch86], and Requirements Engineering using hypertext [Kaindle93]. Requirements are determined by the environment in which the software must be used: "The complexity software systems must handle is the root cause for uncertain requirements." [Bernstein93] "Programmers are always surrounded by complexity; we cannot avoid it[. . .]" [Hoare in ACM 86].
"One of the nastiest challenges encountered in computer systems is coping with unusual events, particularly in situations that were not completely understood by the system developers." [Neuman91]
The bottom line is how well a piece of software fits its environment - having "Requisite Variety" [RossAshby56]. Goodness of fit depends on how well the engineer modeled(understood) the environment and in turn how well the requirements and specifications fit the model [LieteFreeman91]. As Peter Drucker put it in a recent interview:
"There is very little joy in heaven and earth over an engineering department that, with great zeal, great expertise, and with great diligence, produces drawings for the wrong product" [ Wired July/August 1993 page 83].
Formal logic and mathematics help us get a handle on complexity. A logical model of the users' and clients' universe summarizes what is known about the software's environment. The problems and solutions can be shown to fit the environment. The solutions must match specifications. Lastly the software has to be correct versus the specification. The chain from environment to product can be no stronger than its weakest link [Petroski85]. To strengthen the chain, clear and verifiable links connecting the user and the code.
4.5.4 Graphics and Engineering
Gries stated:
"The main activity that is supposed to separate engineering from other fields is design: the actual activity of
preparing plans for some object[..] "page 54,
[Gries91]
Design is the thinking that distinguishes the professional from the amateur. As Capers Jones wrote: "Programming is an intense mental activity that requires some periods of quiet concentration without interruptions." [JonesC95]page 77 cf [LeonardDavis95]
We know that an interrupted process needs to store its state therefore we need a way to store our designs. So one prerequisite is an effective way to represent designs[see bibliography for chapter 7 in Chapter 9]. Once the programmer worked from a flowchart but High Level Languages and pseudocodes replaced the flowchart. In 1983 Ramsey, Atwood and Van Doren showed that using standard flowcharts lead to significantly fuzzier designs than PDL [RamseyAtwoodVanDoren83]. Using design languages makes it is easy to confuse the representation and the object.
Now, Backus, Hopper, etc. invented "programming languages" to code known solutions: (1) formulae (FORTRAN) or (2) documented procedures (COBOL). Numerical analysis was a distinct process done before coding numerical problems [Jackson95]. Similarly work study, cybernetics, systems analysis, and/or operations research enabled efficient solutions to be discovered and then coded in COBOL. Now-a-days programmers try to use a favorite programming language to solve the problem directly. Trying to return to this earlier style Donald Knuth has created tools for "Literate Programming" [see LITERATE in my bibliography]. Others try to use non-sequential texts to describe software [BrownP91] [CybulskiReed92] [Kaindle93] [Nielsen92].
In Software the representation is the product. This distorts solutions to fit the programming language. Even layout can make a difference: experiments show that programs laid out in the traditional "structured" style are harder to understand than those organized like a book [OmanCook90] [BaeckerMarcus90]. Languages can even constrain specifications:-
"[...] programming languages tend to encourage overly restrictive specifications" page 15 of [Lamport86].
Programmers unfamiliar with non-sequential mechanisms fail to find the best solutions to some problems
[McIlroy86] [Hoare78] [Hoare79]. Kenneth E. Iverson argued that"Notation[is] a Tool of Thought" in his Turing Award lecture: "The importance of nomenclature, notation, and language as tools of thought has long been recognized. [...]Concerning language, George Boole in his 'Laws of Thought' asserted 'That Language is an instrument of human reason, and not merely a medium for the expression of thought, is a truth generally accepted.'
Mathematical notation provides perhaps the best-known and best-developed examples of language used consciously as a tool of thought.[...] 'The quantity of meaning compressed into small space by algebraic signs, is another circumstance that facilitates the reasonings we are accustomed to carry on by their aid.' [Charles Babbage]. [...]"
Iverson [ Footnote 10 ] argues for APL. Further modern programming languages are complicated and "If our basic tool, the language in which we design and code our programs, is also complicated, the language becomes part of the problem rather than part of its solution." [ACM86]
Yet even the best language may not be the best tool for finding and solving problems. It cannot guarantee that:
"Engineers are used to communicating with each other by diagrams and sketches and, as soon as they saw diagrams being drawn on the face of a cathode ray tube, many of them jumped to the conclusion that the whole problem of using a computer in engineering design had been solved. [...] graphical communication in some form or other is of vital importance in engineering [. . .]" Maurice V. Wilkes's Turing Award Lecture, 1967 [ACM86].
In 1972, Hoare (speaking to the IERE in London) said:
"[..]a more-or-less precise specification of the product,[...]. For many engineers, architects, painters, or sculptors the specification may be a set of drawings.[...]
"It is one of the most unfortunate aspects of computer programming that there is no intuitively acceptable method of summarizing the major external characteristics of a computer program by means of a 2-dimensional picture or a 3 dimensional model"
[Hoare73].
Compare this with the following interview between Karen A. Frankel(KAF) and Ivan E. Sutherland(IES): [1988 Turing Prize lecture, Sutherland 89].
KAF: You also wrote [1966. . .]"Have you ever tried to pick up somebody else's computer program and understand what it does? [...] I want to look at a display of a computer program and recognize that this part must go with that part just as I can match up the gears in a clock"
IES. I think programming has been treated largely as an alphanumeric task, and most of the work in programming languages and most of the theory of programming and so on has been abstract and alphanumeric. People have simply not made pictures of programs very much, probably because nobody has any ideas as to what a program should look like. I think it might be interesting to do, but I don't have any suggestions as to what they look like either.
Mary Shaw said "One of our problems is that our design notations don't lend themselves to exhibiting and sharing our designs" [MyersW90], compare [ShawM89] and [CSTB 89]. "Hard" engineers always use graphics but, as the above experts noted, "soft" engineers don't have a good standard graphic notation. To make the software process more like engineering, we need better graphics (see p371 [MurphyBalke89]).
. . . . . . . . . ( end of section 4.5 Software Engineering) <<Contents | End>>
4.6 Programming as a Craft
In the last decade of the 20th century a movement emerged from
the underground and gained a great deal of attention under the banner
of agile methods[See
AGILE
for sources]. This essentially promoted a crafts-like approach to
developing software. The work is done by a team working with minimal
paperwork and relying on thorough testing, programmer skill, peer review,
and customer feedback to give the customer what they want. Typically
the team iterates towards a moving target as the customer learns what
they want and the team makes small changes to evolve the code towards
what the user finds comfortable. However there is no lack of discipline
in most of the processes. In some cases (XP) the process is spelled
out in great detail.
What is shared is the idea of trusting the coding skills of the crafts-people. Indeed some [Martin03b] explicitly use the terminology used in pre-industrial times: "craftsman", "apprentice", "journeyman", and "master" to indicate the way that a craft is inculcated in the beginner. There is an implicit (sometime explicit) rejection of academic schooling and engineering style documentation.
These methods work well when the project can be handled in small
incrments and the user representatives are on hand to test and critique
the prototypes. They can fail when the team becomes to big for the
available communication technology to handle. Face-to-face communication
is a key part of many agile methods. This and code constructed in the
correct way replaces traditional documentation. Thus much of the
interface documentation in an XP project is in the form of executable
unit tests and is written first. Similarly changes to code are always
reviewed (in XP) but they are reviewed as they are written by a peer
sitting beside the programmer (pair programming)
4.7 Summary: Art, Craft, Science, or Engineering?
First, it can be dangerous to treat software as an art. This is especially
true when the artist has had no formal training in art. There is an art to
creating user interfaces and readable code but artistic programs are not
necessarily safe, correct, or complete. Errors can occur because
undisciplined creativity does not assure software quality.
Second, engineering is not a science. Science is essential to, but is not engineering. You don't hire a physics graduate to design an X Ray machine. An engineer has a commitment to usefulness and a scientist to truth. Thus, a computer scientist should not be expected to engineer software.
Third, when a scientist makes an error, the direct effect is to damage the scientist's reputation, but when an engineer makes an error other people are damaged [Petroski85] [McFarland90] [Shaw91] [Nissenbaum94] [Collinsetal94]. Therefore engineers must get the more rigorous training [Ford91].
Dijkstra speaks as a scientist when he talks of raising a "fire-wall" between the program and the world in which it exists [Dijkstra89] [Denningetal89b]. Building a firewall around a laboratory does not put out the fire outside the laboratory. Dijkstra is safe but not the users of software because he avoids productivity software Introduction to [Denningetal.89b]. Software needs a fire-proof structure. Fire-proofing knowhow comes from studying fire.
Twenty-five years of research has had a small impact on practice [Parnas95] because the research has been on the "downstream software activities"page 82 of [MorrisonGeorge95] and scientific [Potts93]. Further the model of science in many computer science papers is closer to that of mathematics than an experimental science [Zelkowitz94]..
Problems in software arise in the space between computer science and the world. This is where "software engineering" should fill the gap [CSTB89] [Shaw91] [ChangC93] [Potts93]p18.
Craft is needed in all software development. But it would be a mistake to rely on it if the project is large and life threatening. I hire local painters to paint my house (or do it myself). I do not hire them to choose my color scheme or design and create a university. There is no question that some projects may need more than craft.
Producing good software needs craft plus either luck or good art, good science, and good engineering. Good engineers reject luck and start from an explicit model of the problem area. We now need to develop software knowhow from (1)best practices and (2)best theories rather than trying to develop more pure theories. Therefore to re-engineer software engineering we must first model the current software process, compare p20 of [Potts93] [Hsia93]. As De Millo said: "You of the community have not se