Commits

Herbert Breunung committed 52e97ed

main section prototypes

Comments (0)

Files changed (1)

doc/CompleteProgramming.pod

     highest quality at all levels while still allowing programming be fun.
 
 
-
 =head2 Overview
 
 =head3 DISCLAIMER
     Well, several reasons brought me here.
 
     1) I always wanted a sane balance between the old bureaucratic waterfall method,
-       and the modern extreme or agile programming, which is a bit too shortsighted,
+       and the modern extreme or agile programming, which is a bit too shortsighted
        and accumulates additional work as the project grows.
        It should be possible to combine sound planning, practicability and quick results.
 
-    2) The awesome powers of prototypes are known but still not fully used.
-
-    3) Documentation coverage and depth matters a great deal and writing it
-       would also help the developer.
-
-    4) Writing tests is no silver bullet and is used for several competing purposes.
-
-    5) All methodologies I know of overlook several aspects of the product.
+    2) All methodologies I know of overlook several aspects of the product.
        That includes even "documentation driven development",
        which gave important impulses for the creation of CP.
 
+    3) Documentation coverage and depth matters a great deal and writing it also
+       helps the developer.
+
+    4) The awesome powers of prototypes are known but still not fully used.
+
+    5) Writing tests is no silver bullet. It is used for several competing purposes
+       and in an unnatural way. Thats why a lot of programer hate it.
+
     6) New tools like hg or git allow new workflows which solve pending problems.
 
 
 missing docs are crippling the usability and not findable features are not
 distinguishable from not existing ones. Thatswhy only documented features, libs
 and API's are quality work. And since you wrote them, you should document them.
-It would take more time to explain it to a none-techie. And switching to the
-users perspective - that is what you need to do for good docs - you also need to
-develope good software.
+It would take more time to explain it anyway, especially to a none-techie. And
+switching to the users perspective - that is what you need to do for good docs - 
+you also need to develope good software.
 
 The reason why docs are considered in the "agile" field as less important,
 (agile manifesto says: "Working software over comprehensive documentation")
 because they confuse it with overhead. In CP we don't document planned features,
-just note the in a roadmap. And managers will get high level user docs.
+just note them in a roadmap. And managers will get high level user docs.
 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 to
+that even mangers an understand them. For managers its also helpful to
 understand the language of the user and to know what is actually been done.
 Since the boss will get no special report, it gets harder to cheat or fall into
-other traps of miscommunication, that is enabled by duplication of information
-about one thing. Meetings get more productive too when arguing has a common basis.
+other traps of miscommunication, that is enabled by duplication of information.
+Meetings get more productive too, when arguing has a common knowledge base and
+results will become directly part of the product.
 
 User docs, developer docs and comments, as well as the code itslef are means of
-communication between people. They have to cooperate seamlessly.
-All these parts should have a common language and define key words and phrases
-in the exactly same way. Less friction here is an enormous productivity boost -
-a further reason, why they gotta be written altogether and by the same people.
+communication between people. They have to cooperate. All these parts should have
+a common language and define key words and phrases in the exactly same way.
+Less friction here is an enormous productivity boost - a further reason,
+why they gotta be written altogether and by the same people.
 
-Things not always turn out as planned. So quite often the docs have to be adjusted
-after the implementation of a feature. That oughta be done anyway, because the
-first phase docs were just sketchy drafts, stating what you could know then,
-which always becomes more after the coding. Small iterations between these states
-amplify an holistic understanding and overall quality. The exact rules how to
-iterate are part of the chapter L<Itersations>.
-
+Nevertheless things not always turn out as planned. So quite often the docs have
+to be adjusted after the implementation of a feature. That oughta be done anyway,
+as first phase docs were just sketchy drafts, stating what you could know then,
+which becomes more after the coding. Small iterations between these states amplify
+an holistic understanding and overall quality. The exact rules how to iterate
+are part of the chapter L<Itersations>.
 
 
 =head3 Prototypes
 
-fun
-fast changing
-easy to fork
-sorta test
-stabilizes ideas
-2 tapes: functional and use case
-put into code
-just seperate starter
+One of the things Steve Jobs got right was: "Start with envisioning the user
+experience and then work your way through the technicalities.". CP does that by
+beginning with a bit of user documentation - followed by an explorative phase,
+where developers find out how to realize it by writing prototypes.
+These are small, quickly written programs that are test beds for very few things.
+Usually do programer enjoy building them, because they demand less restrictions
+than huge programs and allow much more fast changes and creativity.
+This way ideas get stable without harming the "real code" and coder have more fun.
+And if a prototype turns out to be a blind alley, it can be deleted without remorse.
+
+Some may now intervene: "Why not just fork an experimental branch, if we using hg,
+git or arch anyway? Afterwards they can be just merged back by the software and
+we don't have to write that code again in the main program.". Well, like said
+dealing with a large program is much more hairy and distracts you from the detail
+you want to get right now. And beside that - a completed prototype has a role
+similar to a test. It demonstrates that a chunk of code works that way. You can't
+practically achieve that while have having a lot dependencies that can introduce
+a failure into an otherwise working piece of code. And in even beside that - 
+in CP we have a way to write prototypes, where the heart can be transplanted
+to the production stream without greater trouble.
+
+Prototypes also serve an educational purpose. Programer often look up how they
+did something in their own programs. That is much easier with nicely sorted and
+indexed prototypes that sit and wait unchanged in their own branch - presenting
+just the essence how to solve one particular problem. Its a kind of documentation
+for programer. But this works only if a solution is also tidied up after its found.
+When you later want to test another idea just clone or copy a similar prototype
+and you already got the needed minimal framework supporting that kind of function.
+All that would be much harder if you just fork a fast changing main program.
+
+CP knows two types of prototypes that are living in two seperate branches.
+Thats because the main program has to bridge two endpoints which are too different
+to think about and optimize for at once. That are the hardware or the near
+hardware software layer and the user. For the one side we have functional
+prototypes and for the second use case prototypes.
+
+=head4 Functional Prototypes
+
+=head4 Use Case Prototypes
 
 
 =head3 Main Program
 
+dummy code
 branches
 cycles
 
 have to change them less
 different angle
 its after thought
+test first doesnt work with gui
+put into code just seperate starter
 
 
+http://testobsessed.com/wp-content/uploads/2011/04/btwq.pdf
+BETTER TESTING — WORSE QUALITY?
+Elisabeth Hendrickson
+
 =head3 Itersations
 
 =head3 Releases