Path: utzoo!attcan!uunet!husc6!mailrus!ames!decwrl!spar!freeman From: freeman@spar.SPAR.SLB.COM (Jay Freeman) Newsgroups: comp.software-eng Subject: Re: Basics of Program Design Message-ID: <1363@spar.SPAR.SLB.COM> Date: 20 Jun 88 19:12:35 GMT References: <900@td2cad.intel.com> Reply-To: freeman@spar.UUCP (Jay Freeman) Distribution: na Organization: SPAR - Schlumberger Palo Alto Research Lines: 64 That's a fascinating subject; there are probably as many different answers as there are programmers. When I am doing a big system, I usually spend as long a time as possible in a design phase, thinking about data structures, algorithms and control flow at a quite abstract level, often accumulating large stacks of notes on paper, backs of envelopes and so on. I don't use software tools too much for this phase, not because there aren't any (an excellent text editor and perhaps a database tool for chasing down reference material would be the premier items), but because I do much of this work in places where there is no computer (in the shower, commuting, sitting in coffee houses, lying in bed trying to get to sleep ...). A key part of the design is figuring out how to bring the system up; I'm sure your professors tell you that getting everything all written, then compiled, then starting to test, is NOT the way! It's important to define a development path that starts with only a few pieces of the whole thing up and running, and ends with a complete system, such that you can move from point to point on the path by adding small modules to the system, in such a way that each module is separately testable by itself and that the system is immediately testable after module installation to see that the integration worked. If the modules are large, then each module is a project in its own right, and has its own development path. The overall development path then becomes a directed graph. The graph may even have cycles -- one does prototypes and throws them away, and so on. When I start to code I generally use a text editor that is sufficiently familiar that I don't have to think about using it, enter algorithms and data structure either in source or in in psuedocode -- structured English -- and then transmogrify them into real source in the latter case. Depending on the language, it is often easier to think about what's going on by looking at psuedocode. With higher-level languages, the psuedocode is less often necessary. Subject to the constraint on maintaining a testable development path, there are several ways to think about the order in which to implement various modules. Top-down is nice and logical, but often leads to lots of stub functions which are difficult to test until you have coded out to the leaves of the call graph; then you have to do lots of careful incremental testing as the effects of "real" functions propagate their way back to the root. Bottom-up is useful if you are sure what primitives you are going to need; you can then write them, test them independently, and start putting them together. Sometimes I develop along the path of least resistance, working on whatever part of the system I think I best understand and am most prepared to deal with. That changes from day to day, of course. A case can be made for thinking hard about what part of the system is riskiest and working on that part as soon as possible -- if the whole thing isn't going to work, you want to know about it as soon as possible so you can work out a fix or do something else. It is often very handy to use a system that provides some kind of top-level interpreter so that you can call and test functions interactively as you create them. Lisp is great for this, as are some of the interpreted Cs. Most traditional systems and application languages fail badly on that score. And in that context it is a useful rule of thumb never to create a data structure without also creating a function that prints it out in a form that humans can read; you end up inserting that function time after time as a debugging aid. My, how I ramble. Hope this is useful or at least provokes thought. -- Jay Freeman