You are probably right about the marketability of "slow" as a movement, but in hacker circles these ideas need to be discussed honestly and directly. The analo

You are probably right about the marketability of "slow" as a movement, but in hacker circles these ideas need to be discussed honestly and directly. The analogy with house building is flawed. Home construction generally follows a preplanned architecture, schedule, and process that has been refined and tested over a long time in an environment which doesn't change much over time. The process of building houses is well understood and if a delay occurs it can be attributed to a lack of skills as you say (or funding problems, etc). Software has a different nature. If you have thoroughly solved a problem, the solution can often be automated. There is no button you can press to build the same house you built once before. It still takes time, money, and materials. With software, if you are not spending a large portion of your time working on a problem that has a novel component or two, you or someone else has probably failed to automate enough. As a result, you never quite possess the necessary skill set to solve your current task. You are always pushing some boundary, even if small. Gross skill set mismatch is a separate problem, of course, but a transient skill mismatch is an inherent aspect of good software development and I don't think it's justified to place any blame on moderate and transient skill mismatches as a result. Whenever you are dealing with something novel, you will need to go slower than usual. It's the same for new types of buildings that use newer construction tools or technology.