Date: Tue, 27 Aug 1996 20:22:08 -0500 From: rkw@shark.dataplex.net (Richard Wackerbarth) To: Terry Lambert <terry@lambert.org> Cc: jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: Am I wrong or is this just stupid?r Message-ID: <v02140b01ae49357c120c@[208.2.87.4]>
next in thread | raw e-mail | index | archive | help
Jordan>> says: Terry Lambert > adds: >> You've consistently cited this as a problem and we've just as >> consistently pushed back on it as a non-problem, asserting that the >> main issue has nothing to do with fear of change and everything to do >> with the LACK OF A WORKING PROTOTYPE TO EVALUATE. > >[ ... ] > >> Well, faith might be cool when it comes to religion, but not in >> engineering. Nobody has ever disputed that the current make system is >> full of holes you could drive a truck through, nor has there ever been >> anything but 100% agreement that the whole tool interdependency issue >> is badly handled and far from any conceivable ideal. >> However, it works No! "It can be worked around" is more nearly correct. There is no reasonable way for me to build a version of "current" to be tested on my small 386 without destroying one of my working servers which are fast, already have the source code, and adequate extra disk space. >> and nobody is going to switch horses until given another WORKING >> alternative. Having the build system broken is simply an unacceptable >> scenario I completely agree. However, my proposed methodology would never leave things any more broken than they already are. By that I mean that I can define a series of steps in the migration from the current situation to the "solution". At each step, by the setting of non-optimal default parameters, we get exactly the same result that we presently get. Once the changes are complete, we "pull the switch" and the same files produce a different structure. Naturally, this would be appropriately tested before it was generally committed to "current". I don't think that the procedure that I have outlined is any more likely to make things unbuildable than a number of recent situations in "current". In fact, I think it less likely to cause a problem simply because I can make most of the changes in such a manner that the bulk of the work has no effect until I change a substitution macro. >> since it stops just about everyone else from getting their work done Why does a change stop everyone? If we agree that we are going to move to an interim step, there will be a set of coding guidelines to be followed. Everyone will be ask to keep those guidelines in mind when writing code-in-progress. I, and anyone willing to assist, will have to examine every line of code to assure that it is in the correct form and fix those that are not. These guidelines would be of the nature of "File includes shall be of the form [...]. The use of [...] is no longer acceptable". Since all of the changes are isomorphic variations of form, they can be coded, reviewed, and tested before they are committed. Once the entire code base has been "translated", the real change can be enabled by changing the .mk files which control the expansion. >I have to say that what Richard wants is a top-down design process, where >you agree on the problem, you agree on the general principles of the >solution, and you agree to ignore the implementation details below that >scale. Well stated, Terry. I would point out that they also include the constraints on the solution as a part of the statement of the problem. One of the constraints would be that the migration MUST be done in steps which never "break" the ability to build a system. That does not mean that there will be no "bugs" in the implementation. However it would include the requirement that changes can be made incrementally and that each design concept WILL be demonstrated before it is committed. >This is a typical process used in industry to communicate "what the market >wants" from marketing to engineering, without engineering having to deal >with delivering on marketings "promise of the week" subsequent to the >agreement. > >It is very helpful to me, as an engineer, to get a firm "here is the black >box" from marketing. It is also good if I can get an agreement for them >to not second-guess my work in terms of their new "requirements", generated >since they made the agreement. >Richard really can't ask for this without offending people, since he is >asking for a fiat, effectively: he wants it acknowdleged that if he takes >it on, it's his bailiwick, to do with as he pleases. It's not quite that case. What I want people to do is review the concept and state the NECESSARY goals. I have outlined a number of key points in the design concept. At every step, I have been met with "We can't do that because I will have to change ...". If no-one is willing to accept change, I have already met that goal by doing nothing :-) >But he's not wrong to want the assurances in the first place. I guess what Jordan wants is the "entreprenaurial" model. I build something and then see if it sells. This is as opposed to the "consultant" model where I apply my expertise to assist the client in reaching their goals. I'm unwilling to do this project on a strictly speculative basis because it is NOT a simple project and I am sure to be able to retire on the "profits".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b01ae49357c120c>