Date: Tue, 1 Apr 1997 16:15:46 -0700 (MST) From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <terry@lambert.org> Cc: nate@mt.sri.com (Nate Williams), proff@suburbia.net, chat@freebsd.org Subject: Re: Internal clock Message-ID: <199704012315.QAA10113@rocky.mt.sri.com> In-Reply-To: <199704012253.PAA12314@phaeton.artisoft.com> References: <199704012229.PAA09779@rocky.mt.sri.com> <199704012253.PAA12314@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I'm not disagreeing, I'm just saying that maintenance time should be > > > front-loaded by breaking the problem into cleanly divisable component > > > areas, etc.. > > > > Easier said that done Kemosabe'. If we all knew exactly what the code > > was going to be used for, had all the knowledge we had going into the > > project that we have at the backend, and how the market was going to > > change we'd all be richer than Bill Gates. > > And BETA is better than VHS, but BETA lost. > > Doing the technically corect thing is a necessary, but not a sufficient, > condition for achieving riches. Huh? What *are* you talking about? I was talking about 'easier said than done', not 'doing it because it should be done.' One is an issue of time/resources, the other is NOT. > I know that this might seem astonishingly naieve, but... why don't you > just *ASK* what the code needs to be capable of doing, and use that as > a design requirements document, and measure your designs against whether > they meet the line items on the requirements doc or not? Second, not many people know *what* is needed, and those that do have completely different ideas on *what* is important/cool/bloat. Sesign by commitee doesn't work. > > The wave of the hand and simple answers simply doesn't cut it, just like > > my silly example below. > > > > > > Really, the issue of putting a man on Mars is designing a good space > > > > ship, not actually building the darn ship. > > > > And, if we design the space-ship correctly, it'll solve all of our > > transportation problems since a space-ship is just a special purpose > > 'transportation' device. So, if we break the problem up into cleanly > > divisable component areas, it'll affect *all* vehicles we design from > > that point on, then all of our transportation problems will go away. > > > This is a strawman; you are comparing unequal levels of abstraction > to try to make your point. No, I'm taking something that's arguably as complex as the 'kernel we all want to have' and applying it to something that is equally complex. You make wide sweeping generalities that sound good on paper, but when the rubber hits the road simply don't work. I've been programming long enough that when my screen starts turning brown that Terry's walking in it again, and it's time to inject a little reality back into the picture. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704012315.QAA10113>