proper planing (CP part IV)

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.

The hugest feature of Perl 6

If there would be an election for the single greatest Perl 6 feature, many would select the box for grammars and others would root for concurrency/async (as expressed in several articles here and elsewhere). Roles and types might be also strong contenders. Here is why I would pick: none of the above, even I like all of them very much.

Resolving conflicts of interests (CP part III)

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.

prototypes vs branches (CP part II)

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.

the core idea behind Complete Programming (tm)(c)

During my last post I mentioned the method of Complete Programming, which started as my knee jerk reaction to the insanities of waterfall and XP. I'm not really big on manifestos but writing down things helps to think clearly and so you might also benefit from thinking about one important principle in CP.