Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83 based; site houxj.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxj!wapd
From: wapd@houxj.UUCP (Bill Dietrich)
Newsgroups: net.unix-wizards
Subject: Re: Decisions in Unix.
Message-ID: <360@houxj.UUCP>
Date: Tue, 8-May-84 10:29:35 EDT
Article-I.D.: houxj.360
Posted: Tue May  8 10:29:35 1984
Date-Received: Wed, 9-May-84 02:07:18 EDT
References: <379@hcrvax.UUCP>, <1209@brl-vgr.ARPA>, <885@elsie.UUCP>, <1260@brl-vgr.ARPA>, <895@elsie.UUCP>, <16Re: Decisions in Unix.
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 47

The main reasons to ask before going ahead and modifying something are :

	- there is half a chance that someone has done it already,
		so you can save the work, perhaps see several different
		ways of doing it, or connect to an emerging standard.

	- by being hesitant about modifying something, you are trying
		to keep it as standard as possible.  This is good
		because
			- your users don't die when they move
				in or out of your environment (suddenly
				the X feature which they used every
				day is gone, and they have to reinvent
				or relearn).
			- your shell scripts don't die when you move
				them (the converse is true;  you
				would like to snag scripts from the
				net without having to also snag
				5 neat modifications to the shell
				that the script depends on).
			- your programs port back and forth (only
				a problem if people are modifying
				kernel, libraries, compilers and/or
				include files, but nothing is sacred
				any more).
			- you don't die when updates or new releases
				are distributed, and suddenly an
				update is no longer semi-automatic,
				and a new release makes all of your
				modifications disappear.

	- after a little thought and searching for existing features,
		and consulting people on the net, you may have had
		time to think further about the modification and
		realized that it isn't such a good idea after all.
		If you had jumped right in and made that little twiddle
		that seemed straightforward, you might have found
		out the hard way a year later that it had the unintended
		effect of making a security hole, screwing up all
		of your backups, or degrading your performance by 5 percent.

In general, being overly aggressive is probably worse than being
overly cautious.


				Bill Dietrich
				houxj!wapd