Idea
The basic idea is simple. Each development block (a piece of functionality ie.) can be characterized using two parameters: visibility and value.
Visibility
Visibility means whether or not the user may see the effect of a block directly. Features seen and used via graphical user interface may be considered visible. Intangible features, such as architecture, are hidden from the user. They are vital, however, as they enable the visible features to be useful.
Value
Value may be either positive or negative. A working feature provides an example of positive value. A broken feature on the other hand is a defect and hence provides negative value.
A hidden feature that provides negative value is considered as technical debt. It may represent some weakness lurking in the architecture. Messy code provides one example of this.
Advantages of Color Coding
It is stated in the article that particularly agile projects tend to produce results that look good but may fail in practice due to demands put on intangible, hidden parts of the software. Software might have all the needed features but it just might not scale in practice due to weak architecture.
Color coding aims to provide means to overcome this issue. It helps project managers to coordinate development better and to avoid postponing important technical decisions before it's too late.
The model seems to provide some sort of compromise between agile and BDUF (Big Design Up Front) ways of development by bringing agile closer to BDUF a little bit. Why not to go BDUF all the way then?
The very gist of agile is that the developers may tap into a rapid feedback loop provided by the customer. This does not happen in BDUF. Of course if you know what you are going to build and need very little room for guidance, BDUF might work just well.
It looks like color coding should provide some well needed stability for agile projects that aim to build software meant to last. It may achieve this by taking the hidden part of software in count during development.
Relation to Kanban
I discussed Kanban briefly in an earlier entry. It looks like it should be possible to apply the idea of color coding there as well. I suppose the benefits stated for agile projects apply more or less to lean ones as well.