[ColinWright]

I do not think that term means what you think it means.[1][2]

This isn't what I understand to be Analysis Paralysis. AP is when you're trying to analyse the problem and design you're trying to code, and you're overwhelmed by the decisions to make and as a result, unable to proceed.

This, in contrast, is about deliberate reflection on what you're doing so you can better make explicit all the otherwise implicit and internal decisions of which you may otherwise be unaware.

As the article says, coders make hundreds of decisions for every routine they write, most on auto-pilot. Some of those might be less than optimal, and this kind of examination and reflection can help to understand, and possibly improve, those decisions.

[1] Minor edit in the light of subsequent comments.

[2] Hat tip to The Princess Bride

[damncabbage]

I got the impression that icandoitbetter was being snide.

[kenkeenan]

Agreed, but some of these questions-- the ones about indent style in particular-- don't seem to me to be the kind of things a developer needs to be thinking about while they're working on getting code written. The endless bickering and bikeshedding that arguments over coding conventions always result in are one thing, but having these arguments with yourself, every time you write a line of code, is crazy!

[ColinWright]

But the point was exactly not to be making these decisions consciously every time you write code. The point - in agreement with you - was that these decisions are not necessarily important.

The argument is that these decisions are made, whether you are aware of them or not, and in this case Beck was undertaking to understand them in nit-picking detail so they can be made visible and better understood, rather than remaining implicit, ill-understood, and possibly sub-optimal.

The author wasn't advocating that this sort of thing be done of every line of code - that would be ludicrous in the extreme. Don't attack the extreme strawman, try to understand and appreciate the underlying purpose.

In my 35 years of software work, far, far too often I see people concentrating on the pointless - bike-shedding if you will - and sadly, this is another case. Concentrate on the point that matters - understanding the processes and decisions of coding, and not the details of the specific instance.

[gruseom]

In my 35 years of software work, far, far too often I see people concentrating on the pointless

The pointless has one great advantage: it is easier to work with. Hard problems are The Unknown, we fear the unknown, and when this fear arises one way to resolve it is by replacing the hard problem with something easier. This is absurd, like the drunk looking for his car keys under the street lamp on the wrong side of the street "because the light's better here", but that doesn't stop us, it just means we do it unconsciously. Now we have a simpler problem that we can concentrate on and (best of all) argue about.

You see this in obvious places like curly brace wars, but there are more interesting examples, such as why editors and version control systems get so much attention. They're important, but not that important. But they're easy to understand and have an opinion about. Better still, they're common across many projects so arguing about them is a way for programmers to socialize.

Perhaps the same pattern is behind our industry's tendency to embrace savior paradigms (Structured Programming, OO, Agile, FP).