Decisions in Unix.

[Bill Dietrich]

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