You're right, and it's a sad fact, but, though they're perhaps secondary to "building something," they're not secondary to building something right. If everyone involved in a product development cycle were appropriately interested in and dedicated to project success, the meetings would run more smoothly. However, I'm reminded of a development project, a blatant example of what happens instead of "doing the job right," that I ran into in the aerospace industry. We had a task to develop a small lightweight flight data recorder for use on the 1553 Bus on the space shuttle. The agreed-upon and signed-off spec called for a WORM drive, on the 5-1/4" form factor that they normally used, with a power budget of about 26 watts and a weight allocation of <4.5 pounds (I'm not certain of this). After inquiring about spec's from the vendors, whose rep's had stood up in meetings when the spec's were being signed off, I ultimately learned that not one of the manufacturers who had claimed to "have" a product that met the requirement that the WORM drive worked on the 1553 bus (a redundant avionics serial bus used in relatively advanced flight equipment) actually had even a functional prototype, or even a realistic "objective" specification for such a device. They had all essentially lied in the meetings, assuming that some "arrangement" could be reached at a later date so their product would be chosen over one of their competitors' offerings. I learned that Cherokee Electronics, a wholly owned subsidiary of Lockheed Electronics was shipping WORM drives to Lockheed for use in their fighter aircraft. In fact, I learned quite a few things that suggested the entire flight electronics industry was in a considerable disarray. Ultimately, I decided to build a bridge between SCSI which would support the drives, to Mil-STD-1553, which was the required hardware interface that the host software expected to use. Unfortunately, another individual, more strategically placed, in a political sense, had, on a previous, albeit not space-flight oriented, flight system development project, successfullyused a 75-pound Honeywell flight data recorder, that used 250 watts or so, and felt that was what should be used. As it turned out, I ended up leaving the project, he got the larger recorder spliced in, though not working, NASA disqualified Martin Marietta from this phase of the project because they totally overshot power and weight requirements and wouldn't give ground, not having a suitable alternative, and, the project was aborted. I guess I was the only one who really cared that the firmly recorded and contracted spec's were met. I'd say that those meetings, do more than give the suits a reason to draw a paycheck, though I'd certainly agree it looks that way. I don't know about the "Powerpoint Bull***t", since it's intended to facilitate "meeting material" generation, but it is worth noting that PowerPoint contains a "bulls**t generator" just to fill the white space before an outline is fleshed-out. It's noteworthy that one of the problems in the industry is that those spec's that are developed in the meetings are often ignored, at least somewhat, by the folks who write code or develop hardware. As a consequence, the success/failure and low/high quality of the end product is on the folks who write the code rather than on the managers who generate those spec's. If managers, who get the credit for the successes, were required by the simple fact that their subordinates follow their instructions instead of doing things irrelevant to the task, which is to follow the spec's whether they work or not, the product development cycle would ultimately be worked out to where it succeeds. Instead, the hipshooting cowboys in the software department end up fighting over the credit for successes and blaming the failures on those in absentia. Dick ----- Original Message ----- From: "Dave McGuire" &lt;mcguire(a)neurotica.com&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Saturday, December 15, 2001 10:25 PM Subject: Re: "Geeks" and licensing what compiling, to I don't agree that firmly establishing what has to be done is "secondary" to the job of doing it. If you're a coder, your job is to follow the spec's you're given. You're not paid to invent alternative ways to do things, but, rather, to implement, and precisely so, the specifications you're given an NOTHING else. I'm not that easily offended. Argument is a useful tool in establishing the truth, BTW. It's just that you have to ensure your arguments aren't fallacious or even completely irrelevant to the point. It's quite true that the problems in programming-in-the-large there are problems not encountered in small programs. Requirements specification is required, even if there's only one line of code, though.