docs/unix-phil: unix-phil.ms comparison

comparison unix-phil.ms @ 10:355ed69a34a8

more about the shell and worse is better (ch03)

author	meillo@marmaro.de
date	Sat, 20 Feb 2010 12:14:01 +0100
parents	529168f49f29
children	b32a43a62cae

comparison

equal deleted inserted replaced

-:529168f49f29
+:355ed69a34a8
 Today, few software designers are aware of these concepts,
 and thus most modern software is limited and does not make use of software leverage.
 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
 .AE
-.if t .2C
+.\".if t .2C
 .FS
 .ps -1
 This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
 Mentor was professor Schweiggert. 2010-02-05
 But one can also specify a numerical argument to define the number of lines to print.
 .SH
 A powerful shell
 .LP
-The Unix shell provides the possibility to combine small programs into
+It was already said, that the Unix shell provides the possibility to
-large ones easily.
+combine small programs into large ones easily.
-But the powerful shell is great feature in other ways, too.
+A powerful shell is a great feature in other ways, too.
 .PP
-It encourages rapid prototyping.
+For instance by including a scripting language.
-It includes a scripting language with built in control statements.
+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.
 This is a great step towards automation.
 It is wonderful if the effort to automate a task equals the effort
 .PP
 Small programs that do one job well, standardized interfaces between them,
 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.

Mercurial > docs > unix-phil

comparison unix-phil.ms @ 10:355ed69a34a8