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 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.
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.
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.
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.
Kephra, Articles, Books, Perl, Programming