4 ms·

Both authors are somewhat wrong, and both authors are somewhat talking about different things (and thus talking past each other). Gavin here is talking about t

Both authors are somewhat wrong, and both authors are somewhat talking about different things (and thus talking past each other). Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change (unless somehow the underlying system changes), and that he is working on almost entirely by himself. And he's taking conclusions from that and applying them to business software, where the requirements are complex, rarely clear, change weekly in often unpredictable ways, and the development team is large and constantly changing over time (as people leave the company and new people come in). This leads Gavin to conclude it is his own cleverness which keeps his code free of tech debt. Phrases like this give away the confusion: > I also do one more thing that almost no developer does: I actually design my code before I ever start coding. This is all well and good! Until you realize in a few months that the business is going in a new direction, and your big beautiful design is now based on a set of faulty assumptions. You either go back to the drawing board (and lose the business time and money) or those new features are going to be bolted on as ugly hacks. (You might even convince yourself "we'll eventually come back and refactor this, surely." Ha!) As for the original author, his mistake was ascribing causation to a correlation. Since all projects he's ever seen that grow in code size gradually accumulate tech debt, he concluded that it is the increase in code size which caused the tech debt. But in reality - Gavin was correct on this point - programming is about developing a mental model for the solution space. Debt arises when the developers no longer possess an accurate model (which they very often don't, when the model they possess is based on a set of vague requirements, and/or when the model that was correct three months ago is now wrong since the business made some new decisions, and/or when the developers who had an accurate mental model when they were working on the problem three years ago have now left the company and the new team don't possess all of the knowledge and context of that era, et cetera et cetera).

gavinhoward 3y ago
> Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change This is not true. I've had requirements change on me before, and I alluded to this with one tiny phrase: > It can happen in two ways: the problem changes (your liability increases) or your software becomes less useful (your asset depreciates). (Emphasis added.) Code liability is directly tied to both the code and the problem. If the problem changes, including requirements, your liability increases. I still suggest that people design though; the act of doing so sometimes reveals flaws and ambiguity that can be worked through early, even if only partially. And design does help keep your mental model more correct.
- wavemode 3y ago
  I wasn't saying the requirements never change. But the frequency and extent of those changes is simply not comparable to the frequency and extent in business software. The features of your `bc` implementation may change, but fundamentally it will always be a command-line calculator. It isn't tomorrow going to need to become Wolfram Alpha.
  - gavinhoward 3y ago
    Fair enough. Though, to my ears, that just sounds like minimizing code liability is more important in that context.

gavinhoward 3y ago

> Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change This is not true. I've had requirements change on me before, and I alluded to this with one tiny phrase: > It can happen in two ways: the problem changes (your liability increases) or your software becomes less useful (your asset depreciates). (Emphasis added.) Code liability is directly tied to both the code and the problem. If the problem changes, including requirements, your liability increases. I still suggest that people design though; the act of doing so sometimes reveals flaws and ambiguity that can be worked through early, even if only partially. And design does help keep your mental model more correct.

wavemode 3y ago
I wasn't saying the requirements never change. But the frequency and extent of those changes is simply not comparable to the frequency and extent in business software. The features of your `bc` implementation may change, but fundamentally it will always be a command-line calculator. It isn't tomorrow going to need to become Wolfram Alpha.
- gavinhoward 3y ago
  Fair enough. Though, to my ears, that just sounds like minimizing code liability is more important in that context.