171–178 of 178 posts
Hang out with mechanical engineers and it won't be long until you hear, "best part is no part". Best code is no code.
Code isn't a product, code is the blueprint for the product. Have you heard mechanical engineers say "no blueprint is the best blueprint"?
Close enough.
Earlier quoted context omitted.
I don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a…
I disagree. Scaling things up has a cost, but not all costs are debt financed. I think the distinction is worth drawing.
The idea that "all code is technical debt" is saying that all code has a non-zero interest rate. In popular parlance though, we don't actually call code technical debt unless we think the interest rate is unnecessarily high.
To try and be more practical, logging is a good example. For some, cleaning up logs once every month or so is just a cost of doing business, it is not avoidable. Similarly, just adding a "grep -v DEBUG" is also just a cost of doing business and watching the logs. Someone else might look at this and call it technical debt, the lack of logrotate & overly verbose logging make all of the above unnecessary.
There are just lots of dimensions to it. To one person, having those DEBUG logs might have been the difference in finding a problem vs not, yet to another those DEBUG logs may never be useful and all they do is create noise. The interest rate we assign to code is incredibly subjective, depending on both task and person.
- Similar to the generality "all code is technical debt" I'll make one of my own: "All technical debt is abstraction assumption failure". You've got an abstraction; you assume it behaves some way; it doesn't. You've got an abstraction; you need to add new functionality behind that abstraction; you assumed this is a good place or a good way to add this functionality; it isn't. The vast majority of technical debt is just this. There may be a couple more categories like "we can't hire people to work in this language" or even something like system performance, but the vast majority of technical debt is a failure of understanding of some abstraction.
- That previous statement does not assert that this is an invalid way of viewing technical debt. "Understanding" the code is literally the most important job of software engineers; less "engineer" and more "museum keeper" sometimes. I've never liked the term "bad abstraction" because it shifts the responsibility of being understood to the abstraction, and not the engineer. It encourages "code bad, rewrite" mentality. Sometimes that is the best course, but I think its always a bad idea to tackle that without understanding the abstraction, and if you understand the abstraction then you probably wouldn't be calling for a rewrite because its "bad"; you'll be calling it for more specific reasons.
- Unilaterally classifying all code as technical debt isn't just wrong; its asinine. "Technical debt" is a useful way of thinking about some code; if you remove that from your lexicon, you may start believing that all code either is or isn't technical debt. If all code is technical debt, your ability to think about the quality of code holistically, with its nuance, is reduced durastically. If you think no code is technical debt, you'll inevitably walk down the path of hyper-engineering perfect giga-systems that, even if they work flawlessly and satisfy all business needs, took way too long to build, cost way too much to run, and inevitably still confuse your replacement in six years.
It seems that the author's focus is on how things can become needlessly complicated, even when trying to implement a seemingly simple feature. However, citing only a few examples is not sufficient evidence. Could we not also consider instances where writing additional code could actually help reducing long-term technical costs?
Aside from this, I found the following points interesting:
> A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones.
> Even when it becomes apparent after the fact that the feature isn’t performing as well as we anticipated, the typical approach is to do nothing. Part of this is the sunk cost fallacy. Often there is the hope that even if the feature isn’t used today, it will be in the future. But there’s also a legitimate reason for doing nothing. Removing a feature also has a cost, both in the development effort needed to cleanly remove it, and in potentially upsetting customers. So once a feature is added to a product, it is almost always there to stay.
Earlier quoted context omitted.
I think it could make more sense if it's rephrased to 'all code is a liability'. Then the equation is simpler. More code = more to maintain = more liability. It says nothing about the quality of the code, just the quantity. Tech debt is a trade-off between near term and long term ambitions - it is literally impossible to build a successful project without accruing this kind of debt, simply because you cannot perfectl…
'All code is a liability' is also not a particularly accurate application of finance jargon. A car or a house also have ongoing maintenance costs, but they would normally be classified as assets (because they generally produce value in excess of the maintenance, or because you can sell them in a secondary market). I think an accurate, useful, but not very catchy rephrasing is just 'working code requires ongoing maint…
If you have a viable solution to a problem that doesn't require code, then you still get the value from that solution without the burden of maintenance.
Classic case in point: your in-house infra platform on K8S is an incredible liability no matter how much value it adds, because it's a means to an end for scaling and serving your product. Or a cost-centre, in other terms. You could just as well host on a collection of SaaS and offload a large portion of the maintenance cost onto the provider.
Rather than writing code that is easy to maintain (read: easy to keep), it's optimal to write code that is easy to discard. The latter is a lot more challenging than piling on architecture and in some sense it's akin to having illiquid code (stuff you can't get rid of very easily), and liquid code (stuff you can get rid of easily).
Earlier quoted context omitted.
> Code is a liability in the sense that it has a non-zero carrying cost. The under-appreciated corollary to that: tests are code, hence tests have non-zero carrying cost as well. > The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs. You understress the complexity point. Higher quantity of code with…
Tests are indeed not free. But neither is having to spend two days to debug a weird bug you would have cought if you had them. Depending on the worst thing your software could be doing if it had a edge case mistake, writing tests is also just another take on trying to prevent them when they happen. Also: nothing prevents us from deleting tests and do as if they never existed, except the nagging voice of sunken cost.
I've worked in so many places where a test suite suddenly takes a day to run with no parallelism, and requires 50 other machines to get it down to 20 minutes. And so many of the tests that waste so much time are down to them being pointless, or being stateful for no reason.
I constantly advise people to stop writing obvious bullshit tests (e.g. the kind of test in Rails where you just assert that you wrote `belongs_to :some_model` in your model), or ones that are too heavily mocked. Focus on your business logic and the inputs and intended outputs, not how you used a framework or dependency.
Earlier quoted context omitted.
'All code is a liability' is also not a particularly accurate application of finance jargon. A car or a house also have ongoing maintenance costs, but they would normally be classified as assets (because they generally produce value in excess of the maintenance, or because you can sell them in a secondary market). I think an accurate, useful, but not very catchy rephrasing is just 'working code requires ongoing maint…
I use the term liability because the only code that has zero maintenance cost is code that doesn't exist. If you have a viable solution to a problem that doesn't require code, then you still get the value from that solution without the burden of maintenance. Classic case in point: your in-house infra platform on K8S is an incredible liability no matter how much value it adds, because it's a means to an end for scalin…
Here you're saying code is a liability because it has costs. But a car or a house have costs, yet they're almost always classified as assets, because the benefits outweigh the costs.
So you're left with a few choices:
1. Accept that code isn't always a liability, at least according to the dictionary definition of the word
2. Argue your way somehow to code nearly always being a net cost (seems unlikely, otherwise why write code?).
3. Redefine the meaning liability for this particular application
I think 1) is the most reasonable choice here.
Earlier quoted context omitted.
I'll take that bet for 5 unmaintained gold bars. If you win you get all 5. If I win you give me 1. I'll let you know when they are buried.
Hmmm. You do realise that if I were to win then the five gold bars would be gone in the wind and you'd be ponying up for another five to pay out on the wager?