lichtkind

As previously mentioned, one principle of Complete Programming is the separation of concerns you normally handle simultaneously. In part two I discuss some further consequences of that and how we use version control in CP.

To complete the picture that I begun to draw last time: in CP we have prototypes for significant low level functions that carry a higher level of uncertainty about how to implement them. Modules/Packages are also implemented at first in their own prototypes as are user level features. These are the the primary three directions you can look at in a software project (low level API, API to the user and internal API). There are 2 other major components more, but lets leave them for the next part. In short we have the actual project code base live separately, as well as a sketch-board where we plan ahead.

One criticism you might have: why rewrite a function four times? First you write it in a function prototype, then its part of a lib prototype, this will be part of a feature prototype, which has results that flow into the code base? I can't be serious to propose to really do this. Well I do and see the benefits. Agreed, my method still needs fine tuning, but the extra burden you sense is the burden of getting it right. Like with TDD we try to iron out issue first and leave good code so we don't have too much nightly debug sessions later.

A functional prototype is a controlled environment where the surroundings are stripped to the necessities. Thus I can see the real dependencies of a function, I can benchmark its pure impact and also write tests for it - long before it flows into the code base. So I have a piece of code that I can and should beautify, so that easy understandable and that gives me the security to grok its impact on the project.

Its also serves as a documentation where, I can look up what a is function really doing and check it for myself, instead of having some blurry sentences in the docs that don't speak to me as a coder.

It also has advantage to be a test lab for further improvements. Instead of making a branch and of a big and complex project, just to mess with one function - I copy a functional prototype and change it. If does what I wanted I make carry the changes over into the related lib proto and test the integration into the library there, before move the changes into the codes base for the next stable version (limit concerns every time).

This might sound to you like it would be done also with branches where the cherry picking of changes is was easier that to adapting the lines to different environments.
This is true but just using VC on bowls of pasta never forces you to think modular. With CP i have the feeling of being in control of the code base. Because I design functions and libs as (as good as it gets) self contained units, the code gets modular with slim and well designed interfaces. If I don't do it CP get painful quickly. It de-motivates you to make sloppy design decisions. And (not tested yet) it should support development by (several) teams well : 1. You can develop stuff without screwing things up for others. 2. Won knowledge is transparent and reusable for other projects. 3. Clear division of responsibilities.