Return to Answer

However

Everything has a drawback

Paul Graham's approach

The artistic equivalent of "beating it into shape" would be repeatedly drawing something badly, erasing (part of) it, and trying (that part) again. That is not what a sketch is, that's just doing something badly and then trying again.

This approach is valuable for learners, as it teaches them the common mistakes that they should learn to avoid in the future, but that is precisely the point I'm trying to make. At some point, you have to move on from the learner phase and stop making those common mistakes, at which point you don't really need to "beat it into shape" anymore.

While learners should shotgun debug to learn the source of their mistakes, any experienced developer, by their very nature of being "experienced", shouldn't be revisiting the basics during their debugging phase.

At that point, debugging is in fact "a final pass where you catch typos and oversights".

The artistic equivalent of "beating it into shape" would be repeatedly drawing something badly, erasing (part of) it, and trying (that part) again. Paul seems to imply that sketching is "expected failure", which it really isn't.

Sketching is still a thoughtful process of reasonable approximation, but it avoids labeling itself as final and instead keeps itself open to alteration if needed.

Shotgun debugging is valuable for learners, as it teaches them the common mistakes that they should learn to avoid in the future, but that is precisely the point I'm trying to make.

A newbie artist doesn't sketch. They paint the whole picture, fail, and then paint over it. It is only when they start to gather enough experience to know how to (not) paint a picture that they start sketching specifically to avoid that try/retry process.

Sketching is what you do to avoid shotgun debugging. Shotgun debugging is not a form of sketching, it's what happens when you don't sketch.

I said that sketching is a reasonable approximation which keeps itself open to alteration if needed. The kind of alterations you need to make to a sketch generally amount to the equivalent of "typos and oversights". If you need to redo your sketch from the ground up, then your sketch must have been really bad or misguided. That's just not good sketching.

While learners should shotgun debug to learn the source of their mistakes, any experienced developer, by their very nature of being "experienced", shouldn't be continually revisiting the basics during their debugging phase.

When you're no longer a newbie programmer, debugging is in fact "a final pass where you catch typos and oversights".

Note of course that real-world waterfall still allows for error correction (no one is that perfect), but the point is that waterfall assumes that what you are building is exactly what you will end up needing.

• You may have overengineered something and wasted time on doing so, also making the rest of development harder to work with this overly complex implementation.
• You may have underengineered something, and because you assumed you were building the right thing, you coupled things too tightly and are now force to make heavy breaking changes.
• The customer has seen our demo and has tweaked the requirements (added/changed/removed some); which inherently means some of our assumptions about what we would end up needing are no long correct, and all logic that depends on these assumptions needs to be revisited. If we already overengineered things, that becomes quite the time sink.

TL;DR

• Both methodologies have real world applications.
• Both methodologies can be overapplied and lead to inefficient results.
• Paul Graham is focusing solely on newbie programmers, overstating himself, or he's overapplying his methodology to the point of being detrimental.

Note of course that real-world waterfall still allows for error correction (no one is that perfect), but the point is that waterfall assumes that what you are building is exactly what you will end up needing.

• You may have overengineered something and wasted time on doing so, also making the rest of development harder to work with this overly complex implementation.
• You may have underengineered something, and because you assumed you were building the right thing, you coupled things too tightly and are now force to make heavy breaking changes.
• The customer has seen our demo and has tweaked the requirements (added/changed/removed some); which inherently means some of our assumptions about what we would end up needing are no longer correct, and all logic that depends on these assumptions needs to be revisited. If we already overengineered things, that becomes quite the time sink.