Date: Tue, 1 Apr 1997 16:42:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@mt.sri.com (Nate Williams) Cc: terry@lambert.org, nate@mt.sri.com, proff@suburbia.net, chat@freebsd.org Subject: Re: Internal clock Message-ID: <199704012342.QAA12413@phaeton.artisoft.com> In-Reply-To: <199704012315.QAA10113@rocky.mt.sri.com> from "Nate Williams" at Apr 1, 97 04:15:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. You were attributing "We'd all be richer than Bill Gates" to having preknowledge, implying that there isn't a formula that you can follow to get the same results. > > 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. What if that committee is named "core"? 8-p. This isn't "design by committee", it's "requirements by committee". The design can be done by anyone who's willing to meet the requirements with a design. Generally, a *individual*, not the committee. > > > 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. The sentence to which the "Mars" example owes its existance is: ] Really, the issue is one of designing good kernel interfaces, not the ] software that plugs into them. Which is about the way in which pieces of the kernel are permitted to fit together, not about the designs of the individual pieces. In particular, my example was the need to repeatedly change the device driver code being a result of changing kernel interfaces, and not of the devie driver itself mutating into unusability. Software does not mutate. The same class of idea can be extended to note the X.25 and ISO networking code falling through the cracks because the person who changed the interface only changed the interface for those modules using the interface which he found "interesting". It's not that the code itself no longer works, it's that the framework was changed without also changing the framework expectations in the "old" code. If we have an interface definition, it should be robust against this type of change, or it is not a good interface definition. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704012342.QAA12413>