Date: Sat, 5 Jun 1999 02:41:27 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: mjacob@feral.com Cc: toor@dyson.iquest.net (John S. Dyson), dg@root.com, wes@softweyr.com, dyson@iquest.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: 3.2-stable, panic #12 Message-ID: <199906050741.CAA57884@dyson.iquest.net.> In-Reply-To: <Pine.BSF.4.05.9906040909190.81993-100000@semuta.feral.com> from Matthew Jacob at "Jun 4, 1999 09:18:13 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob said: > > In terms of design reviews and architecture *before* the commit, well, if > you want to go that route I can assure you it's a major amount of work. It > will bring FreeBSD into "adult" development- no large scale project with > > 50 engineers really succeeds long term without it, but are you really > wanting to the tbings of: MRD (Market Requirement Document), External > Reference Spec, Internal Reference Spec, Test Plan, Architecture Review, > Implementation Review, *Commit*, Test, Release, Post Mortem Review..... > Part of me totally agrees with this (and from the standpoint of being a generally responsible person) all in all do agree. The silly and fun part of me says that all of the fun and the somewhat disorganized nature of creativity should not be destroyed by imposing too many roadblocks in the way of that creativity. The key here is for those with the bottom line responsibility to make the tradeoff between the quality of their (actually the communities') product and making it fun to work on it. I suggest that biasing it slightly in the direction of fun would be best, but most strongly supporting fun and creativity in the areas that need the application of creativity and innovation the most. It seems that a practical aspect of the fun of creativity is for each individual developer to know enough about the work to realize what is reinvention vs. new invention. There have been alot of tradeoffs made in the design of the new (FreeBSD specific) portions of the code, and it isn't likely that those who did not participate directly in the work will know what decisions and tradeoffs were made. Even if the code had comments on every line, and there was a design document associated with every significant subsystem, it would be unlikely that the tradeoffs would be fully disclosed. Some of the tradeoffs made in the past might not be appropriate for now, but others might be quite critical for maintaining some of the positive qualities that FreeBSD is known for today. The above is the reason why gaining access to the decision making process of the past is a choice that allows the maximization of fun in the present, and doesn't loose the positive effects of past work. The negative effects of the creative process are mitigated by the experiences of developers who have alot of history in the field. Loosing that experience in the name of "fun" or even fixing problems that exist in the present will possibly (and in some cases will probably) regress the quality of the code in unintended ways. In a community project like FreeBSD, the notion of ego should really be left alone. The project is best served by the cooperative efforts of all those who are involved, and with ego and impatience being only a secondary or tertiary motivating factor, the group as a whole will benefit the most. The strongest effect that ego had on me when working on FreeBSD was the damage in my name, by me, done to the codebase. Even though there was too much experimental code added to the codebase at the time, there were few other choices available. Perhaps I tended to hold on to the old (hacking) ways too long, but I certainly realized that, and was working aggresively and great restraint to fix that insidious problem well before the time that I had quit the team. (Note that my work was progressing, but also being held away from the tree due to the need to maintain stability, both for altruistic reasons towards the project, and also due to the ego-issue of wanting to avoid breaking or regressing the code.) So, it seems that fun should be a side-effect of working on the project, but that fun should be responsible. Creativity is often associated with fun and enjoyment, and that should not be destroyed by imposing too many rules. I think that the key here is avoiding the negative aspects of ego, and instilling an ethic of responsibility. There are people's livelihoods dependent on the viability of FreeBSD, and fixing one set of problems and causing regressive side-effects in other areas is undesirable. Mitigating the negative side-effects by using available resources, both as an after the fact review aid, and more importantly: in conceptual reviews will maximize the aspects of fun, help mitigate regressions, and in the case of working earlier on with people who have made design decisions before, minimize the friction due to design corrections or reconsideration needed after the fact. No-one wants to redo their programming work, after reviews might be showing that initial design premises are wrong or incomplete. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906050741.CAA57884>