You Shouldnta Decided It

Refers to making a decision, and virtually CastInStone? this result, not only knowing very little about the subject, but also without seeking input about what effect the decision would actually have. Therefore - YouShouldntaDecidedIt. See MicroDecisionAwareness

Some design elements are essential, driven by requirements with little or no room for variation -- say, the use of a particular file format or transfer protocol. Others are accidental -- you chose one way to do something, but there are many other ways. For example, you might use multithreaded processing rather than nonblocking i/o as a means of introducing simultaneity. Accidental doesn't imply wrong. Calling a design choice accidental merely indicates that you have other options, that the direction you went was not essential. It's no great stretch to say that design blunders always occur with the accidental aspects of a design. (After all, you basically have no choice about the essential design.)

A classic blunder of accidental design is overspecification. For example, does this method parameter need to be a HashMap, or is Map sufficient? Must I require explicit acknowledgement for this protocol to work, or can I make do without it? Is this value constant, or might it some day vary?

In a sense, the problem of overspecification is a sort of cousin to YouArentGonnaNeedIt. You made a decision -- with the concomitant loss of flexibility -- that you didn't need to make to get the job done. You introduced a restriction that is not essential. You dind't need to be so specific. When you overspecify, you box yourself (or others) in without good enough reason.

On the other hand, that lost flexibility just might be what "you aren't gonna need". So good programming requires good judgement to know just what constitutes too specific.

Yeah! Excellent thesis. Let's expand this one, eh? [And delete this drivel here.]

CategoryRequirements (a very welcome contribution to this category, by the way)