Justin Kan on Tiered Programming

Much has already been made of the shutdown of Kiko, probably because it shows that Paul Graham isn't Midas who turns everything he touches to gold, and I have little to add there.

I did find Kiko's founder Justin Kan's description of Tiered programming interesting. I've used this approach on multiple occasions, although it seems to be have been missed by the methodology gurus. It is often beneficial to have a developer bushwhacking new features, testing their viability, or working quickly to build a core infrastructure so other developers can get productive. Attempting to tie up every loose end while in this mode can affect the developer's flow, and when a project is new, developers' enthusiasm might be all that there is keeping the project moving. Plus it avoids spending too much time on dead ends.

But if a project continues down this route unchecked it is possible that the end result will be an unusable rat's nest of code. A second developer acting as a groomer can bring the code up to production level, maintainable quality. I've worked in both roles, and if you can remain egoless about your task, it can be a very productive mode of development.