3 ms·

Highlights: > When we program we’re writing down a very explicit and exact description of a solution to our current best understanding of the problem we’re try

by _bxg1 8y ago

Highlights: > When we program we’re writing down a very explicit and exact description of a solution to our current best understanding of the problem we’re trying to solve. Over time both the problem we are trying to solve and our understanding of it will inevitably change, often dramatically. When that happens some percentage of our very explicit and exact description is now wrong, and a liability. Taken to the logical conclusion, given time, every line of code is wrong and a liability that will need to be dealt with. > A little discussed and poorly understood design goal for code is disposability. Criticisms: - I'm not sure I agree that these five buckets are very distinct, nor that they encompass all things referred to as "technical debt". They're good examples worth thinking about, but I don't think they're as archetypical as the author does. - I've never seen it as an assumption that "technical debt" implies "the people before us did a bad job", something the author spends a lot of effort arguing against. The people before you lay out a runway, which helps determine how quickly technical debt will build up, but even the very best codebases accumulate it eventually.

halbritt 8y ago
I was struggling with that last but as well. Sure, in some cases the people before did a bad job, but in my experience that occurs way less often than engineers simply developing for the requirements that they understand, which evolve over time, that is, both the requirements and the understanding. It is possible to create very extensible software architectures, I’ve met many engineers that will spend a great deal of time anticipating future needs, but in many cases this constitutes premature optimization.
- _bxg1 8y ago
  Something I've only recently started to grasp is that good code isn't about taking abstraction and extensibility to the very maximum, it's about picking the right amount of abstraction to fit the amount of change the code will likely face in its lifetime. Abstraction isn't without its own cost. Unfortunately, all of these design decisions - even the meta-decisions like degree of abstraction - are relative to the project and many of them have to be made at the outset, where you're only guessing what the future will bring.

by _bxg1 8y ago

halbritt 8y ago

I was struggling with that last but as well. Sure, in some cases the people before did a bad job, but in my experience that occurs way less often than engineers simply developing for the requirements that they understand, which evolve over time, that is, both the requirements and the understanding. It is possible to create very extensible software architectures, I’ve met many engineers that will spend a great deal of time anticipating future needs, but in many cases this constitutes premature optimization.

_bxg1 8y ago
Something I've only recently started to grasp is that good code isn't about taking abstraction and extensibility to the very maximum, it's about picking the right amount of abstraction to fit the amount of change the code will likely face in its lifetime. Abstraction isn't without its own cost. Unfortunately, all of these design decisions - even the meta-decisions like degree of abstraction - are relative to the project and many of them have to be made at the outset, where you're only guessing what the future will bring.