1. Herbert Breunung
  2. Kephra

Commits

Herbert Breunung  committed 968edb3

further rework of CP head section, shorten more to point

  • Participants
  • Parent commits f165dfc
  • Branches sp3

Comments (0)

Files changed (1)

File doc/CompleteProgramming.pod

View file
     So it is not hard to understand why psychological aspects are most important
     to software engineering and why political and business culture undermine
     the very thing they adore so much.
-    
 
-=head3 Basic Ideas
+
+=head3 Rough Ideas
+
 
     1) The natural progression from a flittering idea to an solid product has some
-       inherent logic and order. Discovering and supporting it, is the main aim of CP.
+       inherent logic and order. Discovering and not sabotaging it is the main aim of CP.
 
     2) In other words: we look for a careful balance between planning and flexibility.
     
        in which one goal has priority. So work becomes more fun, less of a burden,
        manageable, measurable and can be parallelized more often.
 
-    4) Because every subtask has a practical and lasting benefit to the project,
-       there is almost none (felt) overhead.
+    4) They give also the much needed room for experiments without breaking too much.
+
+    5) Because every subtask has a lasting practical benefit to the project,
+       there is almost none (felt) overhead and communication gains quality.
     
-    5) CP relies on honest, open and complete communication which happens through
-       (one|a set of) repository.
+    6) CP relies on honest and complete communication which happens through
+       (a bundle of|one) repository, where everything gets stored.
 
-    6) All parts of the software as e.g. docs, code, comments, tests, artwork
-       and the installer are equally important and without any of them the product
-       is less usable and therefore not complete.
+    7) All parts of the software as e.g. docs, code, comments, tests, artwork
+       and the installer are equally important and without any of them 
+       (in high quality) the product is less usable and therefore not complete.
        
+    8) Tasks / project parts/ responsibilities that belong together, because
+       they rely on the same informations, should be owned by same member/team.
 
 
 
-    2) As a consequence all parts that belong together
-       should also be produced and managed together.
-       District chiefs should be free to make own decisions but also
-       but also bear responsibility for it.
+=head3 Basic Steps
 
+    1) Sketch your goal by writing high level documentation.
 
-    4) We reduce frustration by cutting some administrative tasks and
-       transforming the the rest (as any unloved subtask) to an activity
-       that adds an permanent value to the project.
-       In most cases it has also tangible consequences for worker the in charge.
-       Because any member of the team works on some practical front,
-       communication gains quality too.
+    2) Envision stages in which the program can be released.
+       Particular features or requirements can then be assigned to stages.
 
-    5) The awesome powers of prototypes are known but still not fully used.
+    3) check technical requirements by writing functional prototypes
 
-    6) Software tests are no silver bullet. They are used for several competing
-       purposes and are often not even realistically doable.
-       That's why a lot of programers hate seriously don't like it.
+    4)
 
-    7) New tools like hg or git allow new workflows which solve pending problems.
 
+    5) As soon as you know there will be a variable/method/class or file with
+       a certain name or function, put it in the actual codebase as dummy code.
+       Add comments where supposed to be what.
 
-
-=head3 Main Goal
-
-    Highest aim of CP is the conscience the code is produced with. As result you get
-    
-=over 4
-
-=item a superb overall user experience
-=item quality code
-=item a transparent project planning and status
-=item a room for experiments and changes without trouble
-
-=back
+    9) Write tests after a prototype/feature/lib is done.
 
 
 =head3 Principles
 =over 4
 
 =item Honest and brief communication is key.
-=item Every action is communication and has a productive and lasting (yet changable) result.
+=item Every action is communication 
 =item All code, data and metadata form one project and go into one repository.
-=item They are all equally important, even if they arranged in a structure.
 =item Respect (or change) the structure and avoid any duplication.
 =item Don't plan new feature, document it from users point.
 =item Note the stage it should be implemented in and its technical requirements.
 =back
 
 
+
 =head2 Details
 
+=head3 Observations
+
+
+    1) The awesome powers of prototypes are known but still not systematically used.
+
+    2) Software tests are no silver bullet. They are used for several competing
+       purposes and are often not even realistically doable.
+       That's why a lot of programers hate seriously don't like it.
+
+    3) New tools like hg or git allow new workflows which solve pending problems.
+
+
 =head3 Completeness
 
  Lets start with a small meditation, because Complete Programming (CP) relies on