lichtkind

After explaining the kinds of prototypes that are used in complete Programming and the way code moves between them, it is time the explain the other motivation behind this concepts, before we see the big picture (project planning) next time.

In a large enough project are enough potentials for a clash. We delved a bit into low level API vs use level API vs. internal API and next time it will be about planning vs. concrete implementation. But these are in the end technical issues and can be resolved via pragmatism and enthusiasm for the subject at hand. What bugs many people more personally that program for money is the perceived conflict between management and the coder. These clueless, ignorant and cold hearted penguins can be stressing but why not see them as people too and focus more on the common goal: good software.

The trade-offs I choose for CP give the coder more freedom and a meaningful relation with his (and his alone) part of the project to enjoy it and be proud of it. On the other side allows the compartmentalisation of the project a better detection of dependencies of sub-projects a better planing and even more importantly better tracking of how much work is actually done and how fast the project is moving. Therefore management feels also more in control, can identify bottle-necks and evaluate how realistic a release date really is. It might even slow down the need or overhead for evaluation programs. It enforces honesty a little (something that can hardly be enforced but rather is granted voluntarily), when people can look more into each others cards.

I think neither a strict top down approach that see all people as cogs nor a chaotic hippie movement that celebrates the genius programmer (I look at you: XP) is the most productive. People need room to breath and for experimentation but also an assigned role for better orientation. But they have to be able to meet each other as people with a role and not as their role. And in CP we can even incorporate a genius that doesn't go well along with a team.

For instance by writing functional prototypes and solving hard problems and package them as convenient subroutines for later use. If someone later messes his ideas up, by using a tempered version in a library, he can demonstrate his points with the benchmarks of the functional prototype and pass the blame where is can be rectified.