In "The UNIX Philosophy"  Gancarz gives an important rule. It is something like this: "It's better to have something that works 90% of the time now, than something that works 100% of time later."

The point is that it pays off rapidly to have simple 90% OK scripts + human intelligence for the remaining 10%.  You plugin the 90% of the remaining 10% (actually 9% of the original) when you figure out a neat way to do it.

Typical growth can be classified as horizontal, vertical, and parallel. In horizontal growth the script works under most conditions and fails in certain special cases.  The growth consists of filling in some more special cases.  In Vertical growth the script solves part of the problem and then stops. The user has to provide the missing step.  Vertical growth occurs when a new set of steps is added to the end of a script.  Finally, In UNIX you have parallel growth where a pipe (or socket) connects the old and new parts.

I've got scripts that are 10 years old and still growing.

The other thing that happens is that once scripted you forget about the problem. Some of my pre-teen scripts often seem wiser than I am.

--DickBotting

''I am not sure I agree with the idea of having something work 90% of the time.  I would suggest the goal is to have 90% (or some number) of the functionality working 100% of the time.  The implemented software needs to be reliable more than it needs to be complete.''

----

It sounds like one might want to aim for parallel growth, as connecting small programs with plumbing is the UnixWay.

Out of curiousity, could you provide examples of scripts in the "10 years old and still growing" and "smarter than I am" categories?
----
Here is one of my iterative development techniques:

When doing lots of development in a shell environment, why type in the full path of the shell script when you want to edit it? Try this instead:

 if [ "$1" = "-edit" ] ; then
	exec "${EDITOR:-vi} $0"
	exit 1
 fi

This replaces the invocation of the shell with an editor session that edits the script itself. It's a lot like WikiWikiWeb that way.

-- DavidCymbala

''Just be very careful to remove this functionality when you deploy. Its probably not exploitable most of the time, but it smells like a security hole just waiting for some careless sysadmin to set the SetUid flag.''
----
I agree about the stability -- without it, you're looking at a third party developer who thinks they own the system (even if they don't know it).  They'll take down, override, or replace some innocuous program on the system that happens to be very important or start running a process so high in priority that only a hard reboot would stop it.
WyattMatthews
----
CategoryUnix CategoryUnixShellPattern