Path: utzoo!utgpu!watserv1!watmath!att!dptg!mtunq!psrc From: psrc@mtunq.ATT.COM (Paul S. R. Chisholm) Newsgroups: comp.object Subject: The shape of software Summary: one way in which software design trails other kinds of design Keywords: software design Message-ID: <1174@mtunq.ATT.COM> Date: 9 Jul 90 04:47:47 GMT References: <1638@dinl.mmc.UUCP> <1690@kunivv1.sci.kun.nl> <5239@stpstn.UUCP> <55443@microsoft.UUCP> <5281@stpstn.UUCP> <5286@stpstn.UUCP> <3814@kim> <1278@media01.UUCP> <5337@stpstn.UUCP> Organization: AT&T Bell Laboratories Lines: 90 (I'm going to start by reacting to Brad Cox, and then talking about structured design and other software design efforts. I may ramble a bit, and scare some people off, so let me start off by quoting someone who knows, by his own admission, not one darned thing about computers, and who still manages to summarize my quest better than I can.) "Genrty was convinced that cyberspace had a Shape, an overall total form. Not that that was the weirdest idea Slick had ever run across, but Genry had this obsessive conviction that the Shape mattered *totally*. The apprehension of the Shape was Gentry's grail." --William Gibson, MONA LISA OVERDRIVE, 1988 chapter 10, "The Shape" In article <5337@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > But I absolutely do not agree that software's complexity has to be > greater than that of hardware. Admittedly, it certainly is today, > but isn't that precisely because we still invent and implement > everything from first principles, rather than by relying on and > supporting a marketplace in interchangeable software components? Dr. Cox suggests (here and elsewhere) that we need a paradigm shift, from software *design* to software *construction*. (Dr. Cox, if I'm wrong, please don't hesitate to correct me, by posting or personal e-mail [but note that I've moved slightly].) Personally, I think that having a base of less primitive "primitives" would be nice; and, as Dr. Meyer does, I'd like to never implement a linked list or a table look-up again for as long as I live. But I don't like Dr. Cox's analogy of electrical components (at various scales); that is, I don't think it applies to the problems he, or Dr. Meyer, or Dr. Stroustrup, hope to solve. The design of electronic (hardware) systems works because there are standard components at *all* scales, and customer components at a greater variety of scales can be created and integrated. Dr. Cox's efforts with Objective-C are aimed at supporting the creation (and dissemination) of software components at a higher level that C or C++. He may be successful, and that would be nice; but it's still a single scale. Let me change the analogy, from electronic components to Lego(R) brand childrens' building components. Everything can be built from one and two "peg" blocks. Dr. Cox would like to introduce standard door and window blocks. That would be a wonderful time saver, in a lot of cases; but it doesn't help me when I try to think, "What am I building?" (Duplo blocks are bigger, but don't help, unless I happen to need big blocks.) When I design a Lego construction, I don't think about components of any scale. (That's exactly what I do when I'm playing around, trying to see what I come up with; but that analogy to most software development breaks down fast.) I come up with an overall *shape*, a high-level design that, in the long run, affects how I assemble the pieces; but that is *not* affected by the shapes of the components I happen to have. Architects and engineers (the real ones who design houses and bridges and stuff) do the same thing. They may factor strength-of-materials rules of thumb into their highest level designs, and do the appropriate calculations later; they *don't* think about two-by-fours, I-beams, and concrete forms when they say, "I think I'll put the hallway *here*." (Their customer specifications are also vastly simpler than ours.) Software designers have nothing like that at all; software has no shape. The best thing we have is structured design. (If you haven't read Yourdon and Constantine's book on the subject, log off and pick up a copy; parts of that book are invaluable.) Even so, structured design is a handful of rules of thumb, and a notation based on code structure that breaks down quickly as programs get non-trivial. (Their main contribution is as an intermediary form for going from the data flow diagrams of structured analysis to code; if you don't use data flow diagrams, structure charts aren't likely to be very useful. I'd *love* to have someone argue this point with me.) In software, we have super detailed blueprints that show every stud, every wire, every pipe, and most of the nails; we have nothing similar to an artist's sketch for design. Object-oriented design isn't a solution. It's a very helpful philosophy, and I like what comes out of it. But it can't compare with top down design in terms of being an algorithm for developing software; to do OOD, you think about the problem until you understand it all, and then you implement it from the design in your head. Thanks loads. I've been thinking hard on this subject for over a decade, and haven't come up with anything much. If someone asks me to deliver a software design to them, and I *had* one, I don't even know what I'd hand over. > Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 > The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482 Paul S. R. Chisholm, AT&T Bell Laboratories att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind. Lego is a registered trademark of somebody in Northern Europe.