Date: Tue, 1 Apr 1997 15:53:31 -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: <199704012253.PAA12314@phaeton.artisoft.com> In-Reply-To: <199704012229.PAA09779@rocky.mt.sri.com> from "Nate Williams" at Apr 1, 97 03:29:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Software 'engineering' is something I spent significant time studying, > > > and no matter how good you are maintenance makes up 90% of the 'time' > > > spent on code for most projects. One could argue that the entire > > > FreeBSD project is doing 'maintenance' on the CSRG code tree. > > > > 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. 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? It also seems to me that if we can simply decide to define "the backend" as "now", we would have a good shot at having all of the knowledge that we needed to have to get to the current situation. And then we just build the best design for "now", ignoring historical baggage, with an eye towards making it as generally extensible as we are able, and *hope* that works for two years down the road. And if it *doesn't* work for two years down the road, repeat the process of "successive approximation" until we get there (the Newtonian method is well known because it works, not because it had good PR). > 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. If we realize up front that a spaceship is just a special purpose transportation device, then we should be designing the spaceship so that it will fit into a general transportation framework. We do *NOT* expect the spaceship to solve all our transportation problems. We *DO* expect that any spaceship we design should fit in with a forseeable, from what we know of the general classification "transportation problem", transportation framework, which includes, but is not limited to, spaceships. And that said framework will act as a common basis for soloutions which *WILL*, in combination, solve all our transportation problems. In other words, we have to focus on the big picture, which is where we want to be eventually, not what brush fires we need to put out today. Brush fires are a distraction, and people who are distracted by them should be put to work putting them out instead of planning, since it is hard to shovel dirt while in a blind panic and see into the future at the same time (that's why it's called a "blind panic"). The absolute worst case is that we forsee and build the wrong framework, and have to redo the framework and the outside shell of the spaceship -- and a spaceship is made up of many more things which make it a spaceship than its outside shell, most of which we will be able to reuse. At least we will then be able to consider the soloution of transporation problems in the abstract, and won't look at every new transportation problem as something which can be solved with misapplied spaceships because all we have is spaceships and no framework for thinking about anything else. 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?199704012253.PAA12314>