How can programmers keep track of their design decisions? Let | Not boring, and a bit of a condescending prick

How can programmers keep track of their design decisions?

Let me open up by quoting an okay joke from memory:

If you change random things in your code until it works it’s “bad debugging”, but if you can do it several thousand times a second it is called machine learning and pays three times what you are making now.

One way to understand this joke is to appreciate the power of the simple idea that in the right environment, that embraces natural selection, a bunch of well-tested heuristics generally do the job quite well.

If the above does not look anywhere near the answer you are looking for, kindly allow me to rephrase it in the following way:

• Design decisions are what shapes the implementation in code.

• Good design decisions are the ones that yield implementations that last.

• People with good design decisions get to make more of them later on.

Still not looks like an answer? Okay, let me set the record straight.

It’s not that programmers contemplate a lot on which design decision to make, then make this decision, and then adhere to it. The real world works pretty much the other way:

• The process of settling on a design decision involves multiple proposals and multiple arguments pro and against them.

• Throughout making the design decision, the proposals that were countered successfully are eliminated, with all the arguments against remembered by everyone involved.

• Ultimately, one proposal remains, and is being executed upon. If multiple competing proposals make it to the final round, an authoritative decision is generally being made, with people not agreeing with this decision often times leaving the team or the project or the company.

• It is at this point, when the decision is largely made, optionally, the design doc is written. It may well share some 90% of the contents with what it was during the proposals phase, but, generally, when the design doc is being finalized, the decision has been already made, and, often times, the work has already started.

Now, I hope, the above paints a clear picture that does constitute the answer to the original question.

Software engineers (a.k.a. programmers) don’t really keep track of their design decisions. They don’t have to, because given the information they have obtained during all the discussions before the decision was made, they would make the same decision right away in an eyeblink.

And someone with a strong opinion against the decision that hasn’t been made has either already changed teams, or remembers very well what exactly was the decision they disagreed with, and yet chose to stay on the team despite.

The beauty of engineering, and, especially, software engineering, is that the designs tend to get battle-tested. There’s a real-life feedback look. There’s Skin in the Game, to quote Nassim Taleb.

Software engineering, generally speaking, is no peace-time policymaking game, where arguments are about as strong as they sound to be. Software engineering is closer to a series of war-time campaigns, with the enemy being the laws of nature, systems complexity, and the strength and the dynamics of the team working to implement and later support the designs based the decisions made.

So, most of the time, there’s really no need to keep track of design decisions. What works a lot better is to surround oneself with experienced people who can readily provide plenty of arguments that both stick to everyone’s mind right away, and explain beyond reasonable doubt which decision is and remains the best one given the constraints.