chris@umcp-cs.UUCP (Chris Torek) (06/07/86)
[I have moved the discussion from net.lang.c to net.lang, as it no longer concerns C specifically---nor for that matter does it concern any particular language, but there is no net.coding or net.programming.] In article <441@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >In my own experience, I have ended up pouring [sic] over 500 page specs I hate to sound pedantic (well, perhaps I love to sound pedantic; yet this is still the wrong place for this), but the word is `poring'. (Spelling does not normally bother me, but I have seen this particular error many times recently, and like the `here, here' messages, it just reached the irritant level. Enough.) >and discovered that there were flaws, errors, and "critical windows" >that meant the design could not be implemented. In addition, only >top-level DFDs and S-charts were provided and top-level tasks were >assigned to different people with no "bottom level unification >effort". The result, 20 different flavors of "convert structure >A to structure B". This is certainly a problem. Of course, that designs are often flawed does not necessarily mean designs per se are bad (as you pointed out immediately below); and it is also true that providing only `top-level' information suffices for a small enough project (the limiting case being that with a single programmer). >One of the "Open Issues" of the Yourdon system is whether it is better >to implement "Bottom Up" or "Top Down". One morning not too long ago---or more likely one afternoon or evening---I got up and took my usual shower, and as I finished I realised that here is another way computer science interacts with the `real world': some people dry themselves off `top down', and some `bottom up'. :-) Seriously, I doubt that there is any particular advantage either way. If the tasks implemented by the various routines were properly forseen in the design, it hardly matters when they are written. >... let's look at what can be done. ... Monitoring, in the form >of debug, profiling, metering, etc. should be part of the design, >rather than "Ad-Hoc" tools that get "stripped to the front panal". [sic] Personally, I find that more than a minimum of instrumentation just gets in the way of the code. Compilers can and should, and even sometimes do, assist in this, without interfering with readability. (I will leave `minimum' undefined here; I think it depends on programmer tolerances. `Mill him down another .3 microns!' :-) ) >The bottom line is that production should be part of the design >process, not a middle step in well defined sequence of events. Here I think we just have different definitions. To me `design' cannot include `production', though design can be iterative, with productions interspersed. This makes the two intertwined, but still separate, processes. I would be surprised if this `mixing' did not help to lead to a workable design than otherwise. Whether the amount of help is proportional to the cost is for others to determine, though; I have no experience here. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu