1. Herbert Breunung
  2. Kephra

Commits

Herbert Breunung  committed 5161a19

rework planning

  • Participants
  • Parent commits 6d0e888
  • Branches sp3

Comments (0)

Files changed (1)

File doc/CompleteProgramming.pod

View file
 
  Lets start with a small meditation, because Complete Programming (CP) relies on
 embodying a mindset that is still a bit alien to some. In one word it is holistic -
-meaning seeing the full picture. That includes the users view, programmers view
-and project managers view. Maybe even the designers view. That sounds demanding,
-but you do it already when you really care about something.
+meaning seeing the full (complete) picture. That includes the users view,
+programmers view and project managers view. Maybe even the designers view.
+That sounds demanding, but you do it already when you really care about something.
 
  As a consequence we count an ugly icon, missing documentation or an badly
 designed internal API equally as a bug as a crashing function. CP is designed
 to deliver that high standard, without packing too much burden on the programer.
- Firstly all aspects of a feature are imlepement at once - when details are fresh
-in your memory. And since that also includes comments and documentation, you will
+ Firstly: all aspects of a feature are planned at once - so their in tune with
+each other. And they are also imlepement together - when details are fresh in
+your memory. And since that also includes comments and documentation, you will
 later know what you have done and why, saving a lot of guesswork.
- Secondly we reduce duplicate work and duplicate data where possible and enforce
-the quality of communication and self reflection. Every vital information will be
-in one repository (holistic!).
- And thirdly - the development models knows several decoupled, well defined
-stages - so you only care about one goal at a time. This goal reflects the natural
-possibilities and strengths of this stage. Thats why this work doesn't feels like
-a burden - like for instance writing tests out of the cold (and rewriting them
-several time). Even better - some stages allow free minded hacking and bring back
-the fun - you missed for so long. (Play time and serious time - that is holistic
-too).
+ Secondly: we reduce duplicate work and duplicate data where possible. CP will
+compel you to think about a problem several times, to ensure you unerstood its
+implications. But every time you will produce a useful part of the project.
+Every vital information goes into one well structured repository (again holistic!).
+Your highten clarity and low duplication also improves the quality of communication,
+that will mainly take place through your common work (repository).
+ And thirdly: as hinted, the development model knows several decoupled, well
+defined stages that correlate with the natural flow of ideas into materialisation.
+Any stage has only one goal that is set according to its possibilities and with
+respect to its unavoidable limits. Thats one reason why work gets less heavy.
+(Joyful labour is important to get the deeper focus we need to achieve quality.)
+The other reason: some stages allow free minded hacking and bring back the fun
+you missed for so long. (Play and work balanced - that is holistic too).
+
+The next chapter describe each stage in detail.
 
 
 =head3 Planning
 Duplication leads to unproductive work and enbles miscommunication.
 Managers usually understand such arguments.
 
-
-One last important thing during that phase is to adapt complete programming.
-First you might commit this text as part part of the developers documentation,
+One last, but very important thing during that phase - adapt complete programming.
+First you might commit this text as part of the developers documentation,
 that should reflect briefly all the processes involved. Than you alter details,
-since you program maybe has no GUI, or config, or you will need more branches.
-Maybe will tweak the role of tests becasue by all means these are not the ten
+because your program maybe has no GUI, or config, or you will need more branches.
+Maybe want to tweak the role of tests - by all means these are not the ten
 commandments. And please give us a feedback when your tweaks seem to work well.
 
 
+=head3 Documentation
+
+As you saw, we start always by writing documentation, forwhy its usually better
+to think before doing anything. And putting it down helps you reflect on it.
+Knowing that it will be read by programmer or users should add pressure,
+or let's say serious focus. But please dont overdue it. Just stick to things
+you're sure about and are plannable right now and be sketchy with the rest.
+Than start crafting placeholder code or prototypes that reflect what you just wrote.
+
+
+Because we see code, docs and everything else as one entity, pursuing one goal.
+With bad docs the program is much less usable and enjoyable, hence missing,
+outdated or badly written docs are bugs and should be treated as such.
+
+Many hate writing docs, because its a lot of work when doing it all at once.
+And its even more work when it describes details you already forgot about or 
+were developed by others. But if you see it as part of the codebase and a
+valuable tool for communicating with the back of your head and your coworkers,
+it will become a time saver. And since you always make some kind of plan,
+you have now to write it down only once, only with more conscience (see L<Main Goal>).
+The perceived quality of the program increases hugely.
+
+The reason why docs are considered in the "agile" field as less important,
+("Working software over comprehensive documentation")
+because they confuse it with overhead. In "complete programming" we mostly give
+our managers highl level docs as written for the user. That means we have almost
+no overhead and the docs have to be so good that even mangers an understand them.
+To managers its also better when they know that you actually 
+
+
+types of documentation
+
+
+
+=head3 Prototypes
+
+fun
+fast changing
+easy to fork
+sorta test
+stabilizes ideas
+2 tapes: functional and use case
+put into code
+just seperate starter
+
+=head3 Code
+
 =head3 Coding
 
 
 much faster and you will feel better, because you did already something productive.
 
 
-=head3 Documentation
-
-As you saw, we start always by doing documentation, because usually its better
-to think before doing anything and writing it down helps you reflect on it.
-Knowing that it will be read by programmer or users should add pressure,
-or let's say serious focus. But please dont overdue it. Just stick to things
-you're sure about and be sketchy with the rest. Than start coding placeholder
-code or prototypes that reflect what you just wrote.
-
-Because we see code, docs and everything else as one entity, pursuing one goal.
-With bad docs the program is much less usable and enjoyable, hence missing,
-outdated or badly written docs are bugs and should be treated as such.
-
-Many hate writing docs, because its a lot of work when doing it all at once.
-And its even more work when it describes details you already forgot about or 
-were developed by others. But if you see it as part of the codebase and a
-valuable tool for communicating with the back of your head and your coworkers,
-it will become a time saver. And since you always make some kind of plan,
-you have now to wrtie it only once, only with more conscience (see L<Main Goal>).
-The perceived quality of the program increases hugely.
-
-The reason why docs are considered in the "agile" field as less important,
-because they confuse it with overhead. In "complete programming" we mostly give
-our managers highl level docs as written for the user. That means we have almost
-no overhead and the docs have to be so good that even mangers an understand them.
-
-=head3 Prototypes
-
-fun
-fast changing
-easy to fork
-sorta test
-stabilizes ideas
-2 tapes: functional and use case
-put into code
-just seperate starter
-
-=head3 Code
-
-
-
 =head3 Tests
 
 write after code