marc@txsil.lonestar.org (Marc Rettig) (07/24/90)
Greetings, all. I am working on the first installment of what will be a quarterly column in the Communications of the ACM, entitled "The Practical Progammer." The column will describe ideas and techniques that have worked in practice. Each installment will be accompanied by a sidebar called "Programming in Black and Blue" that describes another approach to the same problem that failed miserably. That's where I need your help. I'd like to hear your tales of blood and gore, of misery and weeping, of good plans gone awry and bad plans forced to completion. The column will range across many issues of interest to programmers, from actual algorithms and code to things like testing and working together as a team. Each quarter I'll post a message like this one, announcing the topic for the next column and asking for war stories. To get things started, here is how the first three installments are shaping up: 1 Working effectively as a team Do you know of a project that failed or went astray because of problems in the team? Was it a problem of organization, leadership, social styles? What happened? How could the problem have been resolved? 2 The development process We design, then code, then test. Right? What do design documents look like? Who reviews them, if anybody? Coding standards? Code reviews? How do you review everything and still have enough time to do your own work? How do you stay on schedule? I'll describe a development process that is working very effectively (few bugs, project on schedule, happy programmers). I'd like to hear stories of what happens when the process isn't planned, or the plans are ignored, or the plans are bad. 3 Testing There should be plenty of horror stories for this topic! Inadequate testing, no testing, making changes after testing was complete, unforeseen conditions that tests didn't cover, and so on. I promise not to publish anything without your permission. At your request, you and/or your company can remain anonymous. If I get several stories, I'll pick the best one or two and use them. If I get lots of stories, I'll use the best ones and post the best of the rest to comp.misc (unless someone can suggest a better place to put them). If there are lots of good ones, we may run the "Black and Blue" sidebar monthly even though the column is only quarterly. So let's hear your stories, folks. We can all learn from each other's mistakes, and we all love to see each other's dirty underwear. ------ Marc Rettig Academic Computing, Summer Institute of Linguistics Contributing Editor, Communications of the ACM
cox@stpstn.UUCP (Brad Cox) (08/04/90)
In article <284@txsil.lonestar.org> marc@txsil.lonestar.org (Marc Rettig) writes: >I am working on the first installment of what will be a quarterly column in >the Communications of the ACM, entitled "The Practical Progammer." The >column will describe ideas and techniques that have worked in practice. >Each installment will be accompanied by a sidebar called "Programming in >Black and Blue" that describes another approach to the same problem that >failed miserably. Although no doubt your Black and Blue column will be most entertaining, I do note that our field is too inclined to savor anecdotal evidence that today's process-centered paradigm has led us into crisis, and inadequately inclined to draw conclusions that might lead to a better paradigm. I'm remined of a journal for 16th century astonomers printing amusing stories about their latest failure to make the Ptolemaic model conform to observations of nature, and neglecting to conclude that the Ptolemaic model was itself the problem. One can even imagine the production of, and solemn agreement with, Black and Blue columns and articles like Brooks' "No Silver Bullet; Essence vs Accidents in Astronomy". I go into this analogy and the need for a paradigm shift in greater detail in an article for Byte magazine, October 1990, titled "There *is* a silver bullet". To paraphrase, a silver bullet does exist, but it is *not* a technology. It is a paradigm shift; replacement of today's process-centered model with a product-centered model; centering on a marketplace in interchangeable software components instead of as today, on languages and methodologies. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
duncan@dduck.ctt.bellcore.com (Scott Duncan) (08/06/90)
In article <5428@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > > To paraphrase, a silver bullet does exist, but it is *not* a >technology. It is a paradigm shift; replacement of today's process-centered >model with a product-centered model; centering on a marketplace in >interchangeable software components instead of as today, on languages >and methodologies. Are you are suggesting that concern for the development process disappears with interchangeable components? What of the process by which those components come into being. Is there no requirements or design process associated with development under the paradigm you offer? I'm not sure how extensively you are using the word process since I do not see it as exclusively the province of creation of code. Even then, I expect creators of software from interchangeable components will follow SOME process in order to combine the components. Can you explain a bit more about how you are using the term "process"? >Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 >The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482 Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (908-699-3910 (w) 609-737-2945 (h))
taylor@limbo.Intuitive.Com (Dave Taylor) (08/07/90)
Brad Cox respondes to an initial request by Marc Rettig with some comments on "today's process-centered paradigm for programming": > To paraphrase, a silver bullet does exist, but it is *not* a technology. > It is a paradigm shift; replacement of today's process-centered model > with a product-centered model; centering on a marketplace in > interchangeable software components instead of as today, on languages > and methodologies. I'll disagree. The key to my rebuttal is that the current evolutionary trend of programming languages is to become more specific, and more customized to a particular niche. Examples abound, including the Prolog language which embodies much information about expert systems, and the MacApp language which offers a high level of self-knowledge about the Macintosh interface. While it is true that the latter, at least, and similar "object oriented languages", accomplish this through the use of user extensible libraries, this too is nothing new. In C on Unix, for example, I've been able to bring in special sublanguages with specific additional features that I've needed for at least ten years, through the use of the "-l lib" flag at compile time. Indeed, my take on this is that the evolutionary step for prog languages is that they become more and more specific, resulting in languages that have a common ancestor and appearance (C, Pascal, FORTRAN, or LISP perhaps) yet can be carefully designed to fit into a specific programming niche. I believe that currently programming libraries offer this functionality. It's really a matter of thinking about things differently; if I want to have a language that looks a lot like C but offers more powerful mathematical functionality the solution is easy; I use "-lm" to add the math library at link time, and voila! Hundreds of new task oriented functions are available for my use. Ultimately what I see us doing is paralleling what happens in spoken languages too; C/Pascal/LISP offers the basic framework for the specialized languages, a framework that we can share and utilize as needed, and the libraries, existing or third-party supplied, offer specialized 'jargons' for the specific niche we're working within. This is completely analogous to the incomprehensible discussion between two professionals in a specific field (computers, medicine, psychology, etc) where individual words can be understood, but the overall point of the discussion can be missed. Obviously, I'm not a big fan of object oriented programming solving all the worlds problems. In fact, I believe that OO is rather an overrated approach to problem solving/programming; like other things, it can be the right solution, but it can also be the wrong solution. And so far, I have never seen a cleanly written, easily comprehended program written in C++, SmallTalk, or any of the other (typically syntactically ugly) so-called object oriented languages. Why do I draw this parallel, then, between programming language evolution and human language (evolution)? Because I believe that programming should be viewed as a type of creative writing; within the confines of a relatively small language, the author must convey (to an annoyingly strict reader/compiler) not only the problem, but the solution too. And ideally, this should be done in such a way that other people can come along later and *read* and *understand* what was written. To flip this around for a sec, a phrase that I've heard as a writer is that "you can always understand your own writing, it's the other people that are the problem". I think that instead of focusing on wierder, more esoteric, and less readable code (C++, for example), our industry should be putting more weight on trying to teach programmers how to communicate to not only their direct audience (the compiler) but the indirect audience too (other people who read/modify the code). Having had the misfortune of reading quite a bit of code from places like Bell Labs, AT&T, UC Berkeley, the University of Utah, Hewlett- Packard, Apple, and other places, all I can say is that it's the RARE programmer who can communicate effectively, with or without legislated coding styles. However, I digress. The point I hope I'm making here is that I don't agree at all with this so-called paradigm shift. I think that the approach to using programming languages as evolutionary problem solving environments is right on. But I don't think that "interchangable software libraries", per se, are going to solve any major problems over and above what we're already seeing today. [ps: interested parties might recall my "Programming Languages: Past, Present and Future" in Computer Language magazine a few years ago.... it talks more about this 'task oriented languages' idea] Just my two cents worth, as they say, -- Dave Taylor Intuitive Systems Macintosh Editor Mountain View, California Computer Language Magazine taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor
marc@txsil.lonestar.org (Marc Rettig) (11/19/90)
Greetings, all.
Thanks to everyone that sent in war stories for the
first "Programming in Black and Blue." Together with
the column it accompanies, "Practical Programmer," it
appeared in the October Communications of the ACM.
I'm now preparing for the second installment. The topic
will be "testing." The column will discuss the question,
"what is 'adequate' testing?" and describe an object-
oriented system that has built-in automated test
procedures.
For the Programming in Black and Blue sidebar, I'd
like to include stories of projects that had problems
with inadequate testing, no testing, bugs that snuck
through testing, unforeseen conditions that were
overlooked in testing, bad management of testing,
and so on.
I promise not to publish anything without your permission.
At your request, you and/or your company can remain anonymous.
Serve the industry--spill your guts on the pages of
CACM.
Thanks much,
Marc Rettig
Contributing Editor, Communications of the ACM
marc@txsil.lonestar.org
Compuserve: 76703,1037