[keithalewis]

Techical debt is primarily about managing complexity, the bane of software engineering. Do not underestimate the value of having a coherent _theory_ about the problem being solved. Something everyone on the team understands and that can be taught to new hires. If you give a programmer a keyboard and a paycheck they will press on keys all day long.

[bokohut]

And if complexity can be designed out from day zero with a clear and concise foundational development model to follow then the technical debt can be greatly reduced as well. This of course conflicts with the global rush into tech to build something as fast as possible to get to revenue and not investing the time proactivity to build for the long game. Planning and control are my two points that get extreme focus in designing that foundation as the world comes to learn the importance of these items impacting cybersecurity, fairly important now-a-days it seems, and so much more. If you know something works then no need to reinvent it every time.

[hinkley]

Designed out on day zero is the siren song of waterfall.

Getting it right the first time is a very hard game to win. It’s best to save some of your energy for the times that really count. It’s always interesting to me when coworkers exclaim that doing the right thing is too hard. Reminds me of myself at age nine trying to get out of chores. More seriously though, “if it hurts stop doing it” is how dumb animals think. Pain is information. Ignoring it is dumb. Almost as dumb as giving up is.

Just last week I was having a hell of a time getting some code to work. Running into a wall. Okay fine, I’ll write more tests. Still struggling. Oh hey, you know what would make this way easier? If I rearranged this code in the manner I thought about this morning but decided to not work on until tomorrow.

If eating the code is difficult, there’s a point of very quickly diminishing returns where adding more logic to the tests is making things worse, and you should think about whether The code is too complicated to test. Maybe you need to remove code, instead of adding it twice.

[bokohut]

After decades of software development experience inclusive of 24/7 on call support while also being the person of which ALL bucks stopped I personally have lived that "hurt" too many times to count. If time can be invested prior by designing out those problems, looking back now, then this is something only experience could bring since one does not know what they do not know.

"Getting it right the first time is a very hard game to win."

I cannot disagree if it is one's first time yet this is my sixth and I have no losses to date. I have nothing but time and so in that time I will see how this game plays out.

[hinkley]

Irreversible decisions are a very small subset of all decisions you will make. If you don't do those at the beginning (or write your code to be agnostic to them, ie, by leaving out feature sets that would surface that decision), then you will be in pain. Experience will tell you which those are, and beginners often have to learn this the hard way. Some never do. Yes let's add localization and security on to the application after it's already 100kLOC and shipped to paying customers. That'll be fun.

Everything else is just annoyance, and lumping those in with the others ends up pulling attention away from the ones that really matter, meaning those solutions get compromised on quality.

Leaving space for a solution is not the same thing as creating an abstraction for a solution, and most people don't get that. Architectural astronauts elevate this blind spot to performance art, and none more profoundly than J2EE architects, as lampooned by Enterprise FizzBuzz: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

I wonder sometimes if some of my former coworkers' cognitive dissonance ends at the office door, or if at home they hang empty picture frames on their walls as placeholders for when they eventually find some art they like, put armchair-shaped boxes labeled "Chair" in their living rooms, dolls in empty cribs and stuffed animals in empty pet beds.

[hinkley]

Technical debt is about managing accidental complexity. But well-placed accidental complexity can make inherent complexity look much, much bigger than it really is.

Clearing debt can be a bit of a fishing expedition, but as long as enough of them have a payoff, it hardly matters if occasionally they come up goose eggs.