steves@ncr-sd.UUCP (03/03/87)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Extracted from "What Price Smalltalk?", Dave Ungar and Dave Patterson, UC Berkeley, IEEE Computer, Jan 87 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ The Architects Trap - After completing a careful and clean design, architects want to improve it with many new ideas. Each idea: - is clever - makes a particular operation much faster BUT, each idea: - increases design and simulation time - does not significantly improve overall performance. A software solution proves to be superior to a hardware solution in every facet except speed. Falling into architect's traps will delay a project, making it less attractive to other competing machines, since it is unlikely that all competing proijects will face the same delays. The bait of the architect's trap is your own ingenuity, but the trap ensnares the whole project, not just the fool who springs it. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Comments ? ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Steve Schlesinger NCR - San Diego
dje@datacube.UUCP (03/03/87)
"The Mythical Man-Month" (author forgotten) is a book based on this concept. It outlines the design of the IBM 360 OS and it's subsequent re-design. The original went pretty well, was efficient, small, fast, and close to schedule and budget. The re-design widely missed all goals due to 'second system syndrome'. Engineers tend(ed) to add in every feature they had thought of since the original design. The author's solution: Design it right the first time. Then go on to new product. I agree with him. You can always design something 'better' given another chance. The great designs are usually done right the first time. Dave Erickson ------------------------ Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 617-535-6644 ------------------------ [ihnp4 | mirror]!datacube!dje
mash@mips.UUCP (03/04/87)
In article <1400@ncr-sd.SanDiego.NCR.COM> steves@ncr-sd.SanDiego.NCR.COM (Steve Schlesinger) writes: > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Extracted from "What Price Smalltalk?", > Dave Ungar and Dave Patterson, UC Berkeley, > IEEE Computer, Jan 87 > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >The Architects Trap - > >After completing a careful and clean design, >architects want to improve it with many new ideas. ...... > Comments ? It's true both hardware and software! (Of course, any RISC person would agree with this, but I've seen it many times). I've used the plague of "creeping featurism" for years in various software engineering talks, and people have given me legions of examples of the bad effects. The only way to fight it is to use rules like: a) PROVE that this feature is worth 1% performance. b) WHEN IN DOUBT, leave it out. c) There is at least one person whose job is to make less of whatever you have. [Like laws: in a 2-body legislature, one body's job should be to repeal laws as quickly as possible.] -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
eugene@pioneer.UUCP (03/04/87)
In article <101200003@datacube> dje@datacube.UUCP writes: > >"The Mythical Man-Month" (author forgotten) is a book based on this >concept. > >The author's solution: Design it right the first time. Then go on >to new product. I agree with him. You can always design something >'better' given another chance. The great designs are usually done >right the first time. > > Dave Erickson The author is Fred Brooks, Jr., the chair at North Carolina, publisher: %I Addison-Wesley %D 1975 YOUR "author's solution" is wrong. He recognized we can't do things right the first time. Unix was not done completely right the first time. Brooks said many things, but not this. He said among other things: Prepare to throw one away and Adding manpower to a late project will make it later. I think he was also one of the first to coin the word "prototype" with respect to software. I suggest your buy the book. It's inexpensive, and sadly, one of the better works of the field (we have not learned much since then). Isn't hindsight wonderful? (Not my quote) From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene
jimv@omepd (Jim Valerio) (03/09/87)
In article <1400@ncr-sd.SanDiego.NCR.COM> steves@ncr-sd.SanDiego.NCR.COM (Steve Schlesinger) writes: > The Architects Trap - After completing a careful and clean > design, architects want to improve it with many new ideas. I dislike this characterization of the trap. It's not obvious to me that an architect's job is ever done. Consider the analogy of Constitutional Amendments. The "architect" of the Constitution completed a careful and clean design for a government, but that didn't mean that further improvements didn't become important and necessary. The world is a diverse place, and it is very difficult to understand all the ways a particular architecture might be used. You can't blame an architect for not knowing everything in advance, or trying to correct an oversight when possible. I believe that a good architect is continually looking for improvements, and arranges to get them incorporated into the design whenever there is sufficient justification for the changes. A bad architect is one who doesn't justify changes, or one who out of hand rejects suggested improvements to "a careful and clean design". -- Jim Valerio {verdix,intelca!mipos3}!omepd!jimv, jimv@omepd.intel.com
mark@mimsy.UUCP (Mark Weiser) (03/10/87)
In article <101200003@datacube> dje@datacube.UUCP writes: >"The Mythical Man-Month" (author forgotten) Fred Brooks, now at U. of N.C. at Chapel Hill. >...outlines the design of the IBM 360 OS. The re-design widely >missed all goals due to 'second system syndrome'. >The author's solution: Design it right the first time. Then go on >to new product. The conclusion I remember from the book is a bit different: don't trust anyone building something for the first, or even second time. Look for the greater-than-two-timers. And if you do have to do something for the first time, prototype, so the critical parts of the final version really aren't your first. -mark -- Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817 After May 1, 1987: weiser@xerox.com"