# HG changeset patch
# User meillo@marmaro.de
# Date 1266664441 -3600
# Node ID 355ed69a34a8127179fce044e5b547d99d60bab5
# Parent  529168f49f29efa4e89a5441dc7eb078113036f3
more about the shell and worse is better (ch03)

diff -r 529168f49f29 -r 355ed69a34a8 unix-phil.ms
--- a/unix-phil.ms	Fri Feb 19 23:11:09 2010 +0100
+++ b/unix-phil.ms	Sat Feb 20 12:14:01 2010 +0100
@@ -32,7 +32,7 @@
 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
 .AE
 
-.if t .2C
+.\".if t .2C
 
 .FS
 .ps -1
@@ -394,16 +394,16 @@
 .SH
 A powerful shell
 .LP
-The Unix shell provides the possibility to combine small programs into
-large ones easily.
-But the powerful shell is great feature in other ways, too.
+It was already said, that the Unix shell provides the possibility to
+combine small programs into large ones easily.
+A powerful shell is a great feature in other ways, too.
 .PP
-It encourages rapid prototyping.
-It includes a scripting language with built in control statements.
+For instance by including a scripting language.
+The control statements are build into the shell.
 The functions, however, are the normal programs, everyone can use on the system.
-Thus, the programs are known and learning to program in the shell is easy.
+Thus, the programs are known, so learning to program in the shell is easy.
 Using normal programs as functions in the shell programming language
-is only possible because they are small, combinable tools in a toolchest style.
+is only possible because they are small and combinable tools in a toolchest style.
 .PP
 The Unix shell encourages to write small scripts out of other programs,
 because it is so easy to do.
@@ -416,6 +416,89 @@
 a mechanism to combine parts to larger parts, and an easy way to automate tasks,
 this will inevitably produce software leverage.
 Getting multiple times the benefit of an investment is a great offer.
+.PP
+The shell also encourages rapid prototyping.
+Many well known programs started as quickly hacked shell scripts,
+and turned into ``real'' programs, written in C, later.
+Building a prototype first is a way to avoid the biggest problems
+in application development.
+Fred Brooks writes in ``No Silver Bullet'':
+.[
+%A Frederick P. Brooks, Jr.
+%T No Silver Bullet: Essence and Accidents of Software Engineering
+%B Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference
+%E H.-J. Kugler
+%D 1986
+%P 1069\(en1076
+%I Elsevier Science B.V.
+%C Amsterdam, The Netherlands
+.]
+.QP
+The hardest single part of building a software system is deciding precisely what to build.
+No other part of the conceptual work is so difficult as establishing the detailed
+technical requirements, [...].
+No other part of the work so cripples the resulting system if done wrong.
+No other part is more difficult to rectify later.
+.PP
+Writing a prototype is a great method to become familiar with the requirements
+and to actually run into real problems.
+Today, prototyping is often seen as a first step in building a software.
+This is, of course, good.
+However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
+After having built the prototype, one might notice, that the prototype is already
+\fIgood enough\fP.
+Hence, no reimplementation, in a more sophisticated programming language, might be of need,
+for the moment.
+Maybe later, it might be neccessary to rewrite the software, but not now.
+.PP
+By delaying further work, one keeps the flexibility to react easily on
+changing requirements.
+Software parts that are not written will not miss the requirements.
+
+.SH
+Worse is better
+.LP
+The Unix Philosophy aims for the 80% solution;
+others call it the ``Worse is better'' approach.
+.PP
+First, practical experience shows, that it is almost never possible to define the
+requirements completely and correctly the first time.
+Hence one should not try to; it will fail anyway.
+Second, practical experience shows, that requirements change during time.
+Hence it is best to delay requirement-based design decisions as long as possible.
+Also, the software should be small and flexible as long as possible
+to react on changing requirements.
+Shell scripts, for example, are more easily adjusted as C programs.
+Third, practical experience shows, that maintenance is hard work.
+Hence, one should keep the amount of software as small as possible;
+it should just fulfill the \fIcurrent\fP requirements.
+Software parts that will be written later, do not need maintenance now.
+.PP
+Starting with a prototype in a scripting language has several advantages:
+.IP \(bu
+As the initial effort is low, one will likely start right away.
+.IP \(bu
+As working parts are available soon, the real requirements can get identified soon.
+.IP \(bu
+When a software is usable, it gets used, and thus tested.
+Hence problems will be found at early stages of the development.
+.IP \(bu
+The prototype might be enough for the moment,
+thus further work on the software can be delayed to a time
+when one knows better about the requirements and problems,
+than now.
+.IP \(bu
+Implementing now only the parts that are actually needed now,
+requires fewer maintenance work.
+.IP \(bu
+If the global situation changes so that the software is not needed anymore,
+then less effort was spent into the project, than it would have be
+when a different approach had been used.
+
+
+
+
+