There are two different questions here: - Why can't we build software as fast as we think? - Why can't we build software as fast as we think we can? The auth

There are two different questions here: - Why can't we build software as fast as we think? - Why can't we build software as fast as we think we can? The author probably meant the latter (which is more associated with estimation and prediction). But I find the former question MUCH more interesting. We've all had the experience of envisioning software solutions that would be useful to us - but then the actual task of developing that software seems much more difficult than the task SHOULD be. I attribute much of this to IMPEDANCE rather than FRICTION. We are often not using the best tools for the job, and hence suffer great amount of superfluous work in solving any particular problem. General purpose programming languages may always have this problem; being able to describe any solution means that they are not particularly well suiting to expressing solutions to particular classes of problems). I've always experienced myself being much more efficient when I have domain-specific languages specifically tailored to the class of problems I want to solve. I think we are moving (slowly) in the direction of developing more targeted languages (e.g. Angular or Dart from Google for client-side web development).