Importance of Ignorance - University of Waterloodberry/COURSES/software.engr/lectures.pdf/... · multi-port Ethernet switching hub. ... This is the only section of the resume that

Importance ofIgnorance

1998 Daniel M. Berry Software Requirements Enginering Importance of Ignorance

Based on:

Importance of Ignorance inRequirements Engineering

Daniel M. BerryJournal of Systems and Software

28:2, 179–184, February, 1995


Requirements Engineering (RE)

“Programmer-Client Interaction in WritingProgram Specifications” by Daniel M. andOrna Berry was written in 1980.


Ignorance Hiding

This paper makes the point that ignorancehiding can be used to hide the requirementengineers ignorance of the client’s domain, byencapsulating that ignorance behindabstractions that can be taken as primitive.


Abstractions

Buzz words

g nouns = types and objects

g verbs = functions and procedures


Practice

Since the paper’s publication, Orna and Danhave practiced ignorance hiding on a numberof requirements engineering efforts.


RE Experiences -1

Many times, though, there was not muchignorance to hide.

• Orna worked in her area of expertise,networking.

• Dan worked in his area of expertise,electronic publishing.


RE Experiences -2

Both were quite satisfied with the generalsuccess of the method and would not use anyother.

Orna, in industry, became known for herability to get to the heart of requirementsquickly and was in demand among severalprojects in the company for which she workedand in other companies.


Most Recent Experience -1

Recently, Dan was called in as a consultant tohelp a start-up write requirements for a newmulti-port Ethernet switching hub.

Dan protested that he knew nothing aboutnetworking and Ethernet beyond nearly dailyuse of telnet, ftp, and netfind.

At one point, earlier in his life, he worried thatthe ether in Ethernet cables might evaporate!



The engineers in the start-up

• were almost exclusively hardwareengineers

• were struggling 4 months to come up witha software requirements document andwere getting nowhere fast

• knew the technology cold but not how tostructure the software for it



The engineers in the start-up (cont’d.)

• had not stated the requirements in full andwere cycling with no convergence betweenrequirements gathering and softwaredesign

• had a much stronger understanding of howto specify hardware, so that the hardwarepart of the project was on schedule but thesoftware part was way behind schedule



Dan asked each person to supply him withcomplete lists of the pieces of the system andof the features (operations) of each.

Dan read these and began to buildabstractions.

Dan noticed lots and lots of inconsistencies.



Dan asked lots and lots of questions andnudged for resolutions of all inconsistenciesduring a 2-hour meeting.

Dan worked for 4 more hours to produce afirst draft specification that seemed to haveelectrified the engineers.



That is, in 6 hours, Dan had put down in wordsand diagrams what the engineers had beentrying to say in 4 months

Dan continued to work over 2 more months toproduce a functional specification and anarchitectural specification that were carefullymaintained to be consistent.


Ignorance is the Key -1

Prior to this most recent experience, whileDan was lecturing at CMU on “Programmer-Client Interaction in Writing ProgramSpecifications”, Jim Alstad remarked thatmaybe the very fact that Dan knew so littleabout Orna’s application area had been asignificant factor in the success of the firstexperience.



By being ignorant of the application area, Danwas able to avoid falling into the tacitassumption tarpit!

The latest experience seems to confirm theimportance of the ignorance that ignorancehiding is so good at hiding.



It was clear to Dan that the main problempreventing the engineers at the start-up fromcoming together to write a requirementsdocument was that

• all were using the same vocabulary inslightly different ways,

• none was aware of any other’s tacitassumptions, and

• each was wallowing deep in his own pit.



Dan’s lack of assumptions forced him

• to ferret out these assumptions and

• to regard the ever so slight differences inthe uses of some terms as inconsistencies.


Retrospective -1

Looking back over the history of applyingignorance hiding, Dan and Orna observed thatthe first and the most recent applications werethe most successful in terms of their ownsatisfaction with the results.


Retrospective -2

History of Ignorance Hiding Experiences

First Most Recent

ignorantexpertignorant

Satisfaction

0

10


Retrospective -3

In the first and most recent cases, therequirement engineer was ignorant of thedomain.

In all other cases, the requirements engineerwas in his or her field of expertise.


Need Ignorance

Our conclusion is that every requirementsengineering team requires a person who isignorant in the application domain, theignoramus of the team, who is not afraid toask questions that show his or her ignorance,and who will ask questions about anythingthat is not entirely clear.


Still Need Experts

We are not claiming that expertise is notneeded.

Au contraire, you cannot get the material inwhich to find inconsistencies without theexperts.


Ignorance, Not Stupidity!

We are not claiming that the ignoramus isstupid.

Au contraire, he or she must be an expert ingeneral software system structures and mustbe smart enough to catch inconsistencies instatements made by experts in fields otherthan his or her own.


Other Sightings

Bob Glass reports how successfully non-software-knowledgeable English majors wereable to write high-quality descriptions of thegrubby details of programs in documentationabout these programs for maintainers.


Recommendations

Each requirements engineering team needs

• at least one domain expert, usuallysupplied by the customer

• at least one smart ignoramus


What if Not Ignorant

What do you do if you’re not ignorant?

Linda McCalla reports that she has becomeexpert in faking ignorance.

“I know that I’ve been fakin’ it!”— Paul Simon

“A Rational Design Process:How and Why to Fake it”

by David L. Parnas and Paul Clements


Resumes of the Future

Resumes of future software engineers willhave a section proudly listing all areas ofignorance.

This is the only section of the resume thatshrinks over time!

The software engineer will charge feesaccording to the degree of ignorance: themore ignorance, the higher the fee!


The Optimist

From the Berlitz Italian Book:

The head of an important firm, looking at anapplication, is astonished when he noticesthat the applicant, though lacking experience,asks for a high salary.

Rather puzzled, he asks him, “Doesn’t it seemto you that you are asking for an excessivesalary, considering the little experience youhave?”


“On the contrary,” replies the applicant. “Workperformed by one who knows nothing about itis harder and should be better paid.”


Mathematicians asIgnoramuses

Martin Feather of JPL on Importance ofIgnorance Paper:

I have often wondered about the successstories of applications of formal methods.Should these successes be attributed to theformal methods themselves, or rather to theintelligence and capabilities of the proponentsof those methods? Typically, proponents ofany not-yet-popularised approach must be


skilled practitioners and evangelists to cometo our attention. Formal methods proponentsseem to have the additional characteristic ofbeing particularly adept at getting to the heartof any problem, abstracting from extraneousdetails, carefully organizing their wholeapproach to problem solving, etc. Surely, theinvolvement of such people would bebeneficial to almost any project, whether ornot they applied “formal methods.”

Daniel Berry’s contribution to the February1995 Controversy Corner, “The Importance of


Ignorance in Requirements Engineering,”provides further explanation as to why thismight be so. In that column, Berry expoundedupon the beneficial effects of involving a“smart ignoramus” in the process ofrequirements engineering. Berry argued thatthe “ignoramus” aspect (ignorance of theproblem domain) was advantageous becauseit tended to lead to the elicitation of tacitassumptions. He also recommended that“smart” comprise (at least) “informationhiding, and strong typing ... attuned tospotting inconsistencies ... a good memory ...


a good sense of language...,” so as to be ableto effectively conduct the requirementsprocess.

Formal methods people are usuallymathematically inclined. They have,presumably, spent a good deal of timestudying mathematics. This ensures theymeet both of Berry’ criteria. Mastery of a non-trivial amount of mathematics ensures theircapacity and willingness to deal withabstractions, reason in a rigorous manner,etc., in other words to meet many of the


characteristics of Berry’s “smartness”criterium. Further, during the time they spentstudying mathematics, they were avoidinglearning about non-mathematics problemdomains, hence they are likely to also belongin Berry’s “ignoramus” category. Thus abackground in formal methods serves as astrong filter, letting through only those whowould be an asset to requirments engineering.

Formal methods proponents would have usbelieve that there is intrinsic value to theapplication of the methods themselves. With


the above considerations in mind, there aretwo ways in which this might be pursued: (1)teach those of us who are not somathematically adept to employ them (andobserve whether or not we succeed); (2)embed those methods inside automated toolssuitable for application, with little extra effort,by non-formal-methods people. If we are tobelieve Berry, we will find some of these toolsthat are deliberately made to be ignorant ofthe application domain to be valuable forrequirements engineering!


The Brainstormers

Dear Dan

Let me tell about our business. Both Sandy &I are writers. We love to express thoughts onpaper. We often write together. We arecomfortable editing each other’s work. Weoften brainstorn (brnstorm, our e-mailaddress) together while writing. We havebeen trying to earn a living writing grantproposals for schools and other non-profitinstitutions. We are both very involved in the


schools. We often develop programs in orderto apply for funds. We have been able to getto the heart of a need, describe it in detail, andsuggest a resolution which appears to befundable. The biggest problem has beengetting paid to do this. We believe ourspecialty is to be able to think in creativepaths. We do not tend to repeat others’ work.I often look at something upside down orinside out. For instance, when faced with theproblem of teachers who have tenure, but areruining kids’ love of learning, I suggestedgiving them no kids, paying their contract as


obligated by union rules, but notcompoundiing the error by also giving themkids to destroy. On more mundane levels, Ioffered to set up charter schools to give thosekids who want a minimum education, and thedegree without having them take and fail thehigher level courses which they were taking tofill in their schedule. This frees up space forthose who really want to take the couorse, andfrees up the teacher from having disinterestedkids. Those kids would graduate anyway, butnow they can get done quicker and make roomfor our growing enrollment.


Basically, we try to think new thoughts. Weoften say that our specialty is NOT knowinganything about your business, so we have nopreconceptions, no blinders, no paradigms toovercome.

A hell of a way to earn a living, eh?

Dick


BRAINSTORMERS!!!!We can think for you,like you’ve never thought before!

Dick NeponSandy [email protected] West Congress StreetAllentown, PA 18104-3104

610.437.9194610.770.0770 [email protected]


Documents

Importance of Ignorance - University of Waterloodberry/COURSES/software.engr/lectures.pdf/... · multi-port Ethernet switching hub. ... This is the only section of the resume that