Essence and Accident in Software Engineering

By: Mike Hastings

“There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.” Frederick P. Brooks, Jr. (1995)

Software Projects = Werewolves Innocent but capable of becoming a monster

No Silver Bullets in Site

InherentData sets, Relationships among data

items, Algorithms, Invocations of functions

ComplexityConformityChangeability Invisibility

No two parts are alike

Scaling up requires increase in elements

Results Communication issues Unreliability Usage difficulties Side effects from expansion

Must adapt to the minds of various people

Must adapt with a variety of applications

Constant pressures for change

Software is infinitely malleable All software changes Users find new uses New hardware forces change

Unvisualizable

No floor plans

Cannot display geometrically

Robs the mind of powerful tools

Leading cause of communication issues

Not inherent

Three steps that attacked major difficulties High-level Languages Time Sharing Unified Programming Environments

What do they accomplish? Frees up most accidental complexity User friendly language Disregards problems from the machine

level

Shortens system response time

Allows for thought retention

Integrated librariesUnified file formatsPipes and filters

Helped develop whole toolbenches Universal tools

Ada – a high-level language of the 1980’s

Pros Improvements in language concepts Focused on step-by-step solutions Encourages modern design

Cons Just another high-level language Low payoff after accidental complexity

removal

Two ideas – Abstract & HierarchialPros

Avoids displaying unnecessary syntax Allows a higher-order-sort of design

Cons Makes no change to essential complexity

of the design

Pros Using computers to solve problems only

humans used to solveCons

Deciding what to say, not saying it

Pros Use of human experts to develop

rules of thumb Inference Engine & Rule Base to

solve problemsCons

Difficult to develop Knowledge acquisition

EXPERT SYSTEMS

Pros Solving a problem from problem

specifications Already proven to work

Cons The solution method is usually required,

not the problem

Pros Applying computer graphics to software

design Flowchart construction

Cons Flow charts are poor abstractions Today’s screens are too small Software is difficult to visualize

Pros Error elimination in design phase Secure operating system kernels

Cons Does not save labor Does not mean error proof

Pros Use of integrated databases to track

detailsCons

Only marginal gains in efficiency

Pros Faster processing time

Cons Still crippled by human "think time"

Attacks on accidental difficulties are limited by the productivity equation:

Time of Task = ∑ (Frequency) x (Time)

Conceptual components are time consuming

Attacks must then address the essence of software problems

Do not construct it at all

Increase in products available for purchase

Delivery is immediate

Sharing cuts per-user cost

Adapt operation processes

Decide what to build Technical requirements Interfaces

Obtain product requirementsRapid prototyping

Simulates interfaces Performs main functions Minimizes hardware, and cost

constraints

The brain is grown, not built Software should be similar

Incremental development Make it run Top-down growing design Allows for easy backtracking Lends itself to early prototypes New functions grow organically

Easier for teams to grow than build

Great designs come from great designers Software construction is a creative process Can empower the creative mind

Great designers are rare How to grow great designers

Identify them early Assign a career mentor Devise a development plan Allow them to interact with other growing

designers

Most accidental difficulties have been addressed

Focus on improving essential difficulties Exploiting the mass market Using rapid prototyping Growing software organically Developing great conceptual designers