lichtkind

After part one (main idea), two (prototypes) and three (sane boundaries of responsibility), I head toward the big picture. How does a project head coordinates planning under a "complete programming" (c) (tm) methodology.

There are many more details about planning in CP I left out for now, because it is already a lot to think about. In the next part I will write about the role of software tests in CP.

If you have a project that is more than a script you have to think about your end goal and how to get there. For these two purposes we have in CP the /dev/overview and the /dev/stage dir.

The first will contain just dummy code. And by dummy I don't mean stupid, but empty subs like "sub with_most_descriptive_name {}" with maybe some comments. The reason for that is: to us programmer code speaks much louder than dead documents. It is part of the project git/hg repo and it changes are transparent.

As soon you know you will need a certain class, put it into the overview. You instantly will get feel for where it sits in the grand scheme of things. And because this is real compiling or interpreted code, all the dependencies have to be in the right order. This way planning mistakes get caught very early. To me it is a far superior way to design your architecture than UML-diagrams. And it also helps to find good names when you see the circumstances of its usage. Having sensible names for all the important identifiers (files, packages and important var names) - is a huge plus which pays off many times in the long term.

Putting dummy libs ASAP in the overview will also give the architect some healthy margin to tweak the design, before the implementation of the libs starts. it also makes sure he speaks the same language as the rest of the team and is actually capable of programming. I not, he should resign. That's also the opinion of martin fowler, who stresses that architecture is a common understanding, so it only can come from a language that is spoken fluently by all participants. But this commonly spoken language also includes the identifier of the project (file package, var names) as already expressed.

Having a directory /dev/overview also follows the main directive of CP: decoupling of concerns. The architect should do its part and the implementors should not worry about details they might screw up for the whole project. Secondly you end goal is decoupled from they way to achieve it. The first stable versions will only implement parts of the envisioned structure - but because the leader never lost the goal out of sight, the growing pains will be less severe. They can be reduced by proper (not too much) planning of stages (stable releases) with an envisioned coherent subset of feaures. Thats the /dev/stage dir is for. This is the archive and planning stage for past and future stable releases. In /bin and /src sits just the current stable for release and bug fix purposes. All the actual development takes place in the /dev dir, hence its name.