I think the brick-laying analogy is a lot more on target than John realises. A lot of the below average programmers go out and start slapping down bricks at a

I think the brick-laying analogy is a lot more on target than John realises. A lot of the below average programmers go out and start slapping down bricks at a great rate of knots. Planning? "Ha! You ain't gonna need it" they say. Design? "Pffftt, is this the bad old days of the PDP-11?" they scoff. "I do automated unit testing, why would I fire up the site in an actual browser? That's so 90s!" The problem is that a lot of the time the bricks they are laying get torn down and rebuilt, and torn down and rebuilt, over and over and over. This gives the appearance of productivity, but gets you nowhere in the long run. Even if you could run at 50mph for hours on end you wouldn't win a marathon by running in the same small circle over and over again. Examples of ways the bricks can go wrong: Not building the right thing (they asked for a gazebo, you built a garage) Not accounting for edge cases (the walls should meet) Not doing proper testing, or leaving the testing until very late in the process Not making the design flexible enough to account for likely changes during the project (no real world equivalent springs to mind) Not building solidly enough (doesn't provide load bearing support in the right places) (closely related to the "catching exceptions is for wussies" school of thought) Leaving odd holes and gaps in the brick wall (security issues) etc. (Feel free to add your own, fun for the whole family! :D )