Path: utzoo!yunexus!geac!daveb From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.software-eng Subject: Re: Writing code/Basics of Program Design) Message-ID: <3008@geac.UUCP> Date: 14 Jul 88 15:48:25 GMT Article-I.D.: geac.3008 References: <900@td2cad.intel.com> <580001@hpiacla.HP.COM> <2992@geac.UUCP> Reply-To: daveb@geac.UUCP (David Collier-Brown) Organization: GEAC Computers, Toronto, CANADA Lines: 123 Organization: Lst week I said... | There are two other basic approaches to a largish project, one of | which is best described as "predictor-corrector", and another best | described as a "modeling" approach. At the request of Stan Osborne @ pbdoc.pacbell, I'll rant briefly about predictor-corrector... About which I'm biased. The term comes from Mathematics, describing algorithms which guess at a starting point, move to that point and then decide which way to move to get closer to the desired answer. In computer science, it really means that one is trying to hit a moving target: one predicts what **should** be the answer, and then finds out why not. In either case, one can discuss it in terms of: 1) how fast it is converging on the target, 2) how expensive it is to do another iteration, 3) how much one can expect to gain by doing another iteration. This means that, once you have captured a customer, one's business managers can discuss how much we're going to make from her in business terms ,without delving deeply into the details of programming. After the first iteration, that is! Specifically, one is doing a series of prototypes, each getting closer and closer to what the customer wants. Consistent with hardware prototyping terminology, we'll call the prototypes the "breadboard", "brassboard" and "printed circuit"... This is a **specific kind** of prototyping approach: not all prototyping fits this model! The Specification Phase: Write a breadboard prototype to test out the user interface and determine the specifications. Don't consider either efficiency or elegance. This one you're unconditionally going to throw away, so don't waste money! Make sure that it really does what the customer wants (well, thinks she wants). Keep trying until you do. Don't stop early! The Design Phase: Now go away into a back room and design a brassboard. Find the architecture that bests maps the task into an achievable implementation. Use whatever mental tools you like, but plan for evolving the program, especially storage structures (using a database is a REAL good idea here), protocols and interfaces. Try to break up the program into three layers: user interface, application proper and core facilities. Plan to write the interface and core facilities as reusable/replaceable independent parts. Implementation Phase 1: Write the brassboard for alpha-testing, in parallel to the customers existing (manual) system. Make the implementation simple: The Unix kernel is full of **very simple** techniques, even though the authors knew the harder, faster ones. Follow their example! Validation & Verification 1: There is no real "unit test/integration test": all in-house tests are integration (verification) tests, all demos are validation tests. Spend time building scripts and test harnesses: you will have to re-run most tests every time you fix something, just to be sure you're not headed towards a maintenance nightmare. At the end of this, you should have a customer who says "It works ok, but its too big and too slow. When do we get the next release?" If you get that question, you've hit the jackpot! Implementation Phase 2: You're writing and releasing versions 1.2 through 1.999, fixing specific performance problems and misfeatures. You're also seeing what's wrong with the design, Don't try to redesign on the fly, save that for version 2.0, but do record what you do/don't like. Validation & Verification 2: Test, and record bug ratios so as to make sure that you're not going backwards. Make sure that the number of bugs is monotonically decreasing and is decreasing fast enough. Implementation Phase 3: "Release 2.0". Now you exit the prediction-correction cycle and use a more formal method to review what you achieved, what you want to change and add. And then do it. But do consider any new/experimental features as individual candidates for the predictor-corrector approach. Weaknesses of this Technique: 1) It works best on hard, poorly understood or politically dangerous problems, 2) It assumes that specifications are hard/impossible to write and validate, 3) The customer must want a short time scale for first product, and be prepared to live with an "early release" to get something functioning, 4) It typically produces code which is a wonderful blend of brilliance and sheer stupidity, so you can't just hand it over to an underpaid "maintenance" group after the first release, you have to keep the lead developers working at it, and 5) Without active involvement of management and the customer, it can into mindless hacking... Conclusion: Its like the girl with the curl: when she's good, she's very very good, but when she's bad, she's horrid. --dave (I love this technique, I use it **inappropriately** all the time...) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | Computer science loses its 350 Steelcase Road, | memory, if not its mind, Markham, Ontario. | every six months.