Category: General Forum Communication Computers Profession Social Aspects

Author

Message Text For: Correct by Design Navigation: Select Threads Forums

Discussion

Date Posted: Tuesday March 02, 2004 10:21:52 AM Jesse Poore suggests a revolution in programming -- holding software developers to the same level of rigor of training and workmanship as other professionals, developing software that's correct by design, and constraining the release of software-intensive products until they are scientifically certified as fit for use. Reply Top Bottom Next Previous

horning

Date Posted: Tuesday March 02, 2004 04:45:32 PM I am highly sympathetic to the goals stated in this interview, and even to much of the prescription for reaching them. However, I feel that in one respect it is too glib: The assumption that we can write complete and precise specifications for software (either before or after it is developed). Having invested many years working in the area of precise specifications, my experience is: 1) It is hard work, at least comparable to the effort currently invested in software development (if maintenance isn't factored in). 2) It is very hard to get the specification right; my experience indicates that the density of "errors" (or "unexpected features") in carefully-written specifications is at least as high as that in carefully-written code. 3) Testing and debugging specifications is probably harder than debugging code, given the present state of tools for both. 4) It is of no use for software to be "correct" (or "proven correct") if it implements the wrong specification. Many advocates of "provably correct software" harm their case by implicitly assuming that software that is consistent with its specification is equivalent to software that does what is wanted. When users discover the difference, they tend to discount the usefulness of precise specifications. To paraphrase Edsger Dijkstra, "Attempts to prove the correctness of software can demonstrate the presence of errors, but should never convince us of their absence." Jim H. Reply Top Bottom Next Previous

culvere

Date Posted: Tuesday March 02, 2004 06:18:33 PM Correct by Design? No, Correct by process I came to programming from one of those more rigorous disciplines (aerospace engineering). Much of my work in aerospace was writing analysis software. Bad specs are part of the problem. However, as noted by Paul de Palma in "A Tale of Two Cultures", ACM SIGSOFT Software Engineering Notes, Vol 28, Issue 6 (November 2003) ), the software culture is a second part. Student engineering competitions concentrate on process and teamwork more than product. Mr de Palma used ASCE's Concrete Canoe contest; SAE has its Formula SAE. ACM's "Battle of the Brains" has _NO_ concern with process: it's a puzzle solving session. A lone student could not, even in theory, win ASCE's Concrete Canoe challenge: the canoe must be raced by at least 2 paddlers (see the ASCE website). For both ASCE's Concrete Canoe and SAE's Formula SAE, the product (canoe or car) is important, but the documentation of the design process and build is also very important. Engineering, as opposed to software engineering, has long realized that real projects cannot be done by an single person. Maybe ACM's next college programming contest should have scoring like this: 20% Specifications document. 20% Software design document 20% Cost and time estimate 20% Test results 10% "Elegance" (whatever that means ) 10% Execution speed Note that the cost and time estimate is to be turned in at the beginning of the project.  Message edited by: culvere on Tuesday March 02, 2004 06:24:04 PM Reply Top Bottom Next Previous

isomerville

Date Posted: Wednesday March 03, 2004 07:05:38 AM Poore is right in what he says about dependable software and we have much to learn from the Cleanroom approach. Unfortunately he doesn't look at the bigger picture. Yes, without doubt we can only create systems that conform to their specification if we use rigorous development methods based around a formal spec. But, for most systems, the stakeholders don't have fixed requirements - these change very rapidly and freezing them in a formal spec. would mean (to paraphrase Barry Boehm) developing the system right but developing the wrong system. Its also unclear if investing large amounts of money in avoiding bugs is more cost-effective than spending money to cope with the consequences of these bugs. In some situations (e.g. a system on a spacecraft) it obviously is but this is not true for many business systems where rapid deployment may be far more important. Our concern should be in developing dependable systems - sometimes this means developing very dependable software and sometimes it means developing mechanisms that cope with and recover from software failure. Too many computer scientists just focus on software without also considering the people, processes and organisations that use that software. Reply Top Bottom Next Previous

Discussion

Date Posted: Thursday March 04, 2004 03:19:03 PM The process of reaching a good specification begins with the best available statement of requirements. The best available is sometimes good and sometimes not very good. Usually it is a combination of oral and written descriptions based on the behavior of other systems, aspirations for new features, better performance, new protocols, etc. The process of reaching a precise specification involves cycles of exposing inconsistencies and incompleteness in the evolving requirements, and resolving them with the cognizant authority (contractor, business rules, etc.). But when it is done, the real requirements have been written out in simple declarative sentences, tables, and equations and the specification is consistent, complete and traceably correct back to the requirements and the authority behind them. This is hard work, but it has a profound effect on making the resulting code smaller, easier to write, verify and test. Moreover, when the requirements change (as they almost always do) it is far easier and safer to drive that change down through the specification, code and test plan than to change code and test plan without benefit of specifications. This is the experience we see repeatedly with the use of sequence-based specifications, incremental development, and usage-model testing. As you say, it is essential to do the right job as well as to do the job right. Reply Top Bottom Next Previous

Discussion

Date Posted: Thursday March 04, 2004 03:20:48 PM Perhaps Barry Boehm was referring to a contracting phenomenon where ¿freezing¿ a set of requirements was a legal act that subsequently obliged the developer to meet the requirements even if they are later seen to wrong, else not get paid. In such a case, the terms take on contracting-cultural meaning beyond the usual software engineering meaning. The starting point is to help the stakeholders converge on a clear statement of requirements. We speak of requirements, specifications and code, in order of increasing specificity as we progress from product or user considerations down to lines of code in a programming language. Nothing is more specific than lines of code. I maintain that it is always easier to write sequence-based specifications in the face vague and changing requirements than to write specific lines of code under such circumstances. From my point of view, things freeze from the top down. Frozen requirements do not imply frozen code, but frozen code always implies frozen requirements. As you say, one should focus on the people, processes and organizations, and I think this means one must focus on the less specific requirements before even thinking about writing very specific lines of code. As to cost and schedule effectiveness, in our experience, even small first time efforts are able to absorb the learning time. Larger projects gain in both schedule and cost. Experienced teams going from project to project become very efficient and effective. Reply Top Bottom Next Previous

slichten

Date Posted: Friday April 09, 2004 06:12:37 AM I have a comment to make about the premise that other professionals provide perfect service. They don't. Do doctors always cure their patients? Do architects design the house we really wanted (or do we simply pretend that they did)? Do gardeners design the garden just how we wanted it? Does the dressmaker sew a costume that fits perfectly? No. None of these professionals is perfect, and few do their jobs to macth customer requirements. Yet, they 'get away with it' and are not told that their product or service 'failed'. Yet in IT and systems, we are constantly accused of poor ability and work and told our systems have 'failed'. How do we react to such criticism? We agree that we have failed! We self-victimize. How do doctors react to attempts by patients to criticize their work/diagnoses/treatment? They deny that they did anything wrong, and band around one another in support. No doctor will criticize another doctor's judgement. How does that compare with our profession? We can't wait to acknowledge that another analyst did not define the user requirements properly, or that their system design was poor, or that the programs were not tested thoroughly, etc. Until systems professionals gather round one another and support eachother as a community of professionals, we will continue to be held to impossible standards of perfection, as Jesse Poore has now suggested, apparently. Reply Top Bottom Next Previous

Navigation: Select Threads Forums

[ACM]   [Ubiquity]   [ACM Privacy Policy]