1.1 --- a/unix-phil.ms	Fri Feb 05 14:06:43 2010 +0100
     1.2 +++ b/unix-phil.ms	Fri Feb 05 16:40:51 2010 +0100
     1.3 @@ -1,4 +1,4 @@
     1.4 -.if n .pl 1000i
     1.5 +.\".if n .pl 1000i
     1.6  .de XX
     1.7  .pl 1v
     1.8  ..
     1.9 @@ -24,18 +24,25 @@
    1.10  Why the Unix Philosophy matters
    1.11  .AU
    1.12  markus schnalke <meillo@marmaro.de>
    1.13 -.AI
    1.14 -.ce 0
    1.15 -University Ulm
    1.16  .AB
    1.17  .ti \n(.iu
    1.18 -This term paper discusses the importance of the Unix Philosophy in software design.
    1.19 +This paper discusses the importance of the Unix Philosophy in software design.
    1.20  Today, few software designers are aware of these concepts,
    1.21  and thus most modern software is limited and does not use software leverage.
    1.22  Knowing and following the tenets of the Unix Philosophy makes software more valuable.
    1.23  .AE
    1.24  
    1.25 -.2C
    1.26 +.if t .2C
    1.27 +
    1.28 +.FS
    1.29 +.ps -1
    1.30 +This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
    1.31 +Mentor was professor Schweiggert. 2010-02-05
    1.32 +.br
    1.33 +You may get this document from my website
    1.34 +.CW \s-1http://marmaro.de/docs
    1.35 +.FE
    1.36 +
    1.37  .NH 1
    1.38  Introduction
    1.39  .LP
    1.40 @@ -91,7 +98,7 @@
    1.41  %T The Art of UNIX Programming
    1.42  %D 2003
    1.43  %I Addison-Wesley
    1.44 -%O .CW \s-2http://www.faqs.org/docs/artu/
    1.45 +%O .CW \s-1http://www.faqs.org/docs/artu/
    1.46  .]
    1.47  .LP
    1.48  These different views on the Unix Philosophy have much in common.
    1.49 @@ -109,20 +116,50 @@
    1.50  .NH 1
    1.51  Importance of software design
    1.52  .LP
    1.53 -why design at all
    1.54 +Why should we design software at all?
    1.55 +It should be general knowledge, that a bad plan is better than no plan.
    1.56 +As stated earlier in this document, the process of building a software
    1.57 +means going from an idea to a release.
    1.58 +The development process tells how to get from the idea to the release.
    1.59 +Software design tells how the built software should look like.
    1.60 +.PP
    1.61 +It is not enough that the released software offers all requested functionality.
    1.62 +It is a misbelief that only function matters.
    1.63 +Building a software the first time is only a small part of the overall work.
    1.64 +The larger part begins when the software is released for the first time
    1.65 +\(en maintainance and extending work..
    1.66 +This part soon covers more time than the time which was needed to build the software the first time.
    1.67 +.\" cf. brooks?
    1.68 +.PP
    1.69 +The extendability and maitainability of a software highly depends on its design.
    1.70 +Good design eases these tasks much.
    1.71 +Bad design, in contrast, requires much more effort for maintaining and
    1.72 +extending the software.
    1.73 +Developers should, for their own best, have maintainability and extendability in mind
    1.74 +when they design the software.
    1.75 +.PP
    1.76 +Users of the software do not care about maintainability and extendability,
    1.77 +at least not directly.
    1.78 +They care about usability and flexibility.
    1.79 +They want the software to directly solve their problems.
    1.80 +They want to be able to to use all its functions if they learned a few of them.
    1.81 +They want to use the software for similar tasks.
    1.82 +Software is successful if users enjoy using it.
    1.83 +Good software design can offer great flexibility and usability.
    1.84 +.PP
    1.85 +Good design matters for developers \fIand\fP for users.
    1.86 +Hence both groups should care about good software design.
    1.87 +Bad design limits the software in some way.
    1.88 +It may still provide all requested function, but it will have worse quality,
    1.89 +and thus require more work effort for developers or frustrate users.
    1.90 +.PP
    1.91 +Good software design is to the implementation like data structures are to algorithms
    1.92 +\(en if you get the former right, then you do not need to care about the latter,
    1.93 +it will simply go the right way.
    1.94 +.\" cf. ??? ``good data, bad algos''
    1.95  
    1.96 -- for dev mainly: extendability and maintainability
    1.97  
    1.98 -- for users: usability and flexibility (but you need to learn how to use it)
    1.99  
   1.100 -no design and bad design limit the use of software
   1.101 -
   1.102 -.NH 2
   1.103 -Architecture
   1.104 -.LP
   1.105 -the most important design decision.
   1.106 -
   1.107 -the topic here
   1.108  
   1.109  .NH 1
   1.110  The Unix Philosophy
   1.111 @@ -137,6 +174,13 @@
   1.112  enabler pipe
   1.113  
   1.114  .NH 2
   1.115 +Architecture
   1.116 +.LP
   1.117 +the most important design decision.
   1.118 +
   1.119 +the topic here
   1.120 +
   1.121 +.NH 2
   1.122  Interface architecture
   1.123  .LP
   1.124  standalone vs. tool chain