Exploring the Relationship Between Software Engineering and Engineering Practices

The Relationship of Software Engineering and Engineering Dror Feitelson Hebrew University

Different Opinions The optimist: Mary Shaw Maybe not like chemical engineering or bridges, but still engineering The less optimistic: Philippe Kruchten It s different, but we can cope The pragmatist: Bertrand Meyer Luckily, in most cases it doesn t matter My opinion Not even close Where it does matter we re heading for disaster

Mary Shaw, Prospects for an engineering discipline of software . IEEE Software 7(6), pp. 15-24, Nov.-Dec. 1990 Mary Shaw, Continuing prospects for an engineering discipline of software . IEEE Software 26(6), pp. 64-67, Nov.-Dec. 2009 Mary Shaw, Progress Towards an Engineering Discipline of Software . SATURN 2015 Keynote CS professor at CMU since 1972 Chief scientist of SEI 1984-7 Co-director Sloan Software Industry Ctr. 2001-6 Fellow of the ACM, IEEE, AAAS

So What Is Engineering? Creating cost-effective solutions constraints / tradeoffs to practical problems should work by applying codified knowledge experience / science to build things real, not abstract in the service of mankind ethics Engineering enables ordinary people to do things that previously required virtuosos

Software Engineering A label applied to a set of current practices for software development Not really an engineering discipline Arguably has a potential to become one Insights by comparing with other engineering disciplines Differences from other fields: Costs in design, not manufacture; coding is actually detailed design hard to automate Constrained by intellectual complexity, not physical laws

Development of Engineering engineering commercialization craft

Development of Engineering engineering commercialization Amateurs and virtuosos Knowledge does not propagate Waste of materials Small scale production Little commercialization craft

Development of Engineering Skilled craftsmen Training in operational procedures Concern for cost and materials Large scale production Manufacture for sale engineering commercialization craft

Development of Engineering engineering Educated professionals Use scientific analysis and theory Enabling of new applications Specialized market segments commercialization craft

Where is Software Engineering? (And where is computer science?) engineering commercialization craft

The Situation with Software data structures algorithms state machines frameworks Tools (IDE) engineering rare cases if any lifecycles commercialization most software production craft most startups early large systems (SABRE)

The Situation with Software data structures algorithms state machines frameworks Tools (IDE) lifecycles engineering rare cases if any commercialization most software production typically called software engineering craft most startups early large systems (SABRE)

Terminology What we call software engineering is actually tools, technology, and management practices Calling this engineering diverts attention from what needs to be done Need to focus on creating the theory and science for a real engineering discipline

Path to True Engineering Define body of knowledge needed by experts 50,000 chunks of information 10 years of learning Attempt to start this: the IEEE Software Engineering Body of Knowledge (SWEBOK) Looks like a laundry list of everything anyone on the committee thought was potentially important (335 pages), with little if any assessment and prioritization

Path to True Engineering Define body of knowledge needed by experts Make this knowledge accessible Finding it should be easier than deriving it anew: this has happened with Internet search Documentation of libraries etc. Wikis, howtos, forums, and crowdsourcing extensiveness and currency at the price of authority, accuracy, and organization

Path to True Engineering Define body of knowledge needed by experts Make this knowledge accessible Repetition and reuse Design patterns Libraries, templates Integrated environments Cut and paste examples from the web?

Path to True Engineering Define body of knowledge needed by experts Make this knowledge accessible Repetition and reuse Professional specialization Nobody can master everything Specialization in technologies like real-time, numerical computing Specialization in application areas like vision or transportation Specialization in problem classes like HCI and adaptive systems

Path to True Engineering Define body of knowledge needed by experts Make this knowledge accessible Repetition and reuse Professional specialization Improve coupling between science and commercial practice

Measuring Progress The software development problem will never be solved We will always build systems at the edge of our capabilities Progress is measured by the expansion of this edge, And by the growth in the number of classes of problems that are solved routinely

Peter J. Denning and Richard D. Riehle, Is software engineering engineering? . Comm. ACM 52(3), pp. 24-26, Mar 2009 Worked on Multics at MIT Inventor of the working set model for paging of virtual memory Writer on the computing profession Professor at several universities President of the ACM 1980-1982

Aspects of Computing Widely accepted: Mathematical aspects of computer science Scientific aspects of computer science Computer hardware engineering Controversial: Software engineering Do software development practices deliver reliable, dependable, and affordable software?

Learn from Other Engineers Predictable system behavior Software often exhibits surprising behavior (bugs) Design tolerances What the system can tolerate usually unspecified Failure probability Hard to manage software risks Separate design from implementation In software there is little specialization

Four Roles Software architect Gather requirements and create specifications with full system view Software engineer Create economic and effective system design, address conflicts and constraints Programmer Convert engineering design into working tested code Project manager Handle coordination, schedule, and resources

What Does This Solve?

Philippe Kruchten, Putting the 'engineering' into 'software engineering' . Australian Softw. Eng. Conf., pp. 2-8, 2004 Developer of several large systems, e.g. Canadian air traffic control system Professor of SE, Univ. British Columbia Developer of the Rational Unified Process

Science vs. Engineering Science: unconstrained study of laws, trends, and models, with emphasis on rigor and formalism Goal: knowledge and truth Engineering: perform trade-offs and compromises to make products with given level of quality under constraints of time, money, personnel, and legacy Goal: build useful things efficiently

Software Engineering Definition According to IEEE Standard 610.12: the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software

Differentiating Characteristics Software is different from other engineering disciplines: No fundamental theory Computer science doesn't really help understand software Compiled code is unstructured and brittle: a bug in one place causes effects elswhere Software engineering limited to using best practices

Differentiating Characteristics Software is different from other engineering disciplines: No fundamental theory Ease of change Much more so than bridges etc. But hard to do rigorously and take all ramifications into account

Differentiating Characteristics Software is different from other engineering disciplines: No fundamental theory Ease of change Rapidly evolving technology Can't consolidate body of knowledge Can't benefit from many years of experience Need to continuously retrain engineers

Differentiating Characteristics Software is different from other engineering disciplines: No fundamental theory Ease of change Rapidly evolving technology Negligible manufacturing cost Easy to re-deliver a fix, so no pressure to get it right the first time

Differentiating Characteristics Software is different from other engineering disciplines: No fundamental theory Ease of change Rapidly evolving technology Negligible manufacturing cost No borders Easy to outsource: don't need to ship goods

Consequences I Waterfall model doesn't work It does in other fields where things don't change Need to use iteration and incrementation Accommodate change Validate by execution and use, because theory doesn't exist

Consequences II Composability is problematic Even if components are good, we don't know whether their composition will be Again due to lack of theory And to the fact that technology changes rapidly Possibly alleviated by architecture and model- driven design

A True Profession Define and teach the body of knowledge What works in practice Professional certification programs Liability and responsibility for products Shift from an inner focus (playing with technology) to an outer focus (satisfying user needs)

Bertrand Meyer, The ABC of software engineering . Technology+ blog, 25 March 2013. Professor at ETH Zurich Teaching of object-oriented programming Eiffel programming language and IDE Design by contract Recipient of ACM Software Systems Award

Not Everything is the Same A physicist writes a 50-line Matlab script A Microsoft employee maintains Word A programmer works on flight-control software Do they all need the same level of engineering ?

C = Casual All kinds of useful things Should work properly May compromise on software engineering: Occasionally crash Hard to understand by others Works only on one platform Eats up too much memory Etc. Probably most of the software written Good enough is good enough

B = Business Run key processes of an organization Must satisfy strict quality requirements Failure will cause significant losses Requires use of solid software engineering practices

A = Acute Must work exactly right Failures lead to loss of life and/or other terrible consequences Requires best of best practices E.g. formal verification Typical of infrastructure software Transportation systems, power grid, nuclear But also personal medical devices

State of the Practice

Real Engineering Example Question form structural engineering certification exam

The Solution

Software Engineering Equivalent Given a class comprising 300 SLOC, with given measured characteristics such as algorithmic complexity, that was tested according to a standard white-box testing scheme, what is the probability of observing a failure within 6 months of deployment? But, We don t know what the main factors are We don t know how to measure them We don t know how to express their effect in a formula

What We Do Have Best practices Tools Uncertainty and change Creativity What about regulation?

C. A. R. Hoare, The emperors old clothes. Comm. ACM 24(2), pp. 75-83, February 1981. Inventor of Quicksort (at age 26) Inventor of switch/case construct Took responsibility for null references Inventor of Hoare Logic Inventor of formalisms like CSP Recipient of 1980 Turing Award (and many other awards)

On Algol 60 Subset Implementation Every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

Whats Wrong Here?

Under the Hood <form method="post" action="http://www.pikiwiki.org.il/login/do-login" class="login"> <input type="text" name="email" class="form-control email" placeholder="email"/> <input type="password" name="password" class="form-control" placeholder= password /> <button type="submit" class="btn btn- info">Enter</button> </form> [Fixed within a few days after being notified]

Making of an Apocalypse Software is ever more prevalent How many computerized systems have you used today so far? Software is ever more crucial All the infrastructure around you All the dynamics of a living society Software production is not improving enough Incentives favor time to market over quality Only a major catastrophe will change this