6 ms·

> They end-up making there managers happy, yet in the long-run everybody is panicking and they are considering refactoring or even building the application from

by dahdum 2y ago

> They end-up making there managers happy, yet in the long-run everybody is panicking and they are considering refactoring or even building the application from scratch after 4-5 years. As mostly a startup dev I’ve never worked in a company with a runway long enough to afford worrying about a potential rewrite 5 years in the future. I’ve had to rewrite some of the most spaghetti founder code ever, but surviving long enough to do so was a sign of success. Author isn’t wrong per se, but code purity isn’t always a worthwhile goal, and needs to be balanced by the needs of the business. Virtually all of the code I’ve written over the years has been tossed by acquiring companies moving everything to “their stack”, acquihire, company shutting down, product pivots, or better 3rd party software becoming available/affordable. I’ve pushed some trash tier code over the years because it worked just well enough to drive growth/revenue and keep the lights on.

freefaler 2y ago
Indeed, my own experience in my several companies confirms this. Yes, code quality is important, but we write code to solve a problem for the paying customer. If we can't solve it on time and on budget it doesn't matter how well it has been written. If you survive long enough you'll refactor the parts that are important. Also some parts are more important than other, everything with money calculation and potential data loss should be written more carefully.
- Spivak 2y ago
  I've always called this "good problems to have." If you're at the point where your slapped together solution doesn't cut it anymore then it means you're successful enough to actually need better. Don't use the solutions to hard problems when you don't have hard problems yet. Because they're making trade-offs to meet constraints that you're not under. Ranch dressing at the grocery store has to be shelf stable and they make a bunch of compromises to get it to that point. The ranch dressing you make it home can be better easily by just ignoring those constraints.
- f819934580bd48f 2y ago
  > potential data loss should be written more carefully. Doesn't this apply to any code that touches data intended to eventually be persisted? If so, IMO this applies to a huge portion of all software, I would guess more than half, because writes tend to be much more complex than reads IME.
  - freefaler 2y ago
    Data loss usually occurs when you "migrate", "backup/restore", "upgrade" data. A stupid internal tool can wreak havoc because it's something non-customer facing with less stringent testing. The bugs on CRUD operations are usually ironed out early and can be limited to a small subset of data being lost. However a mingled migration script from one table to another is a really dangerous stuff but frequently it's treated as "internal tool". Floating point calculation and storage is also tricky and should be written/tested with greater care.
haswell 2y ago
> I’ve pushed some trash tier code over the years because it worked just well enough to drive growth/revenue With all respect, this summarizes everything I’ve come to hate about our industry over the years. I understand why this happens, and I’ve also been the person churning out crappy code at points in my career. But I think it also highlights how backwards the incentives have become, and we’re constantly seeing the real world impact playing out as the next zero day, the next botnet, the next Boeing scandal, etc. I’m not saying there’s never a place for bad-but-working code, but I’m increasingly convinced it never belongs in customer facing products, and that we have a major task ahead of us collectively to correct the mindset behind this and fix the incentive structure that enables this. Software runs the world now, and a frighteningly large number of software companies do not take their position of power seriously.
- bschmidt1 2y ago
  Is code more like poetry or more like a recipe? If the former, then yes we should be allowed the time and space to craft the highest syntactic art imaginable. But if it's the latter, it should just be quick, correct, readable, and extensible. If it's art - how dare you ruin my masterpiece? If it's business - we had a solution deployed for the customer in less than an hour. If syntax (poetry) is your #1 take your time. If money is your #1 you wouldn't call it "crappy code" at all. Even code that is not as performant as it could be is only "crappy" if it's affecting the bottom line (which it often does). But so-called bad code that is yielding higher profits, hard to call crappy.
  - OrigamiPastrami 2y ago
    > If it's business - we had a solution deployed for the customer in less than an hour. Boeing was good at finding cheaper solutions to business problems as well. In the end it's society that suffers for our tolerance of late stage capitalism. There is no "right" answer to this. But tolerating crappy engineering because it's cost effective seems like an admission of defeat to people that actually want to make things better. It's not so much letting perfect be the enemy of good enough; it's more about the steady decline in quality because that's what we incentivize.
fidotron 2y ago
A former colleague of mine had a good way to describe it: technical debt is like financial debt, too much will kill you but if you don’t have any you will be outgunned by those that do. The trick is how to manage tech debt properly, and the widespread scrum fake-agile in use provides no means for ever tackling tech debt once taken on. This is one reason for the explosion in SRE teams.
- marginalia_nu 2y ago
  > A former colleague of mine had a good way to describe it: technical debt is like financial debt, too much will kill you but if you don’t have any you will be outgunned by those that do. Yeah, this is a very astute observation. It's also worth noting that the cost of technical debt is higher for larger organizations. Refactoring is very cheap when you're just one or a few people, but prohibitively expensive to the point of impossible when working in a much larger organization. I think it's generally a bad idea to write code to large-organization standards when you're working alone. It makes your process much more rigid than it needs to be. The great benefit of flying solo or with a small team is exactly how nimble you can be, the small cost of re-writes and even throwing stuff away.
  - fsckboy 2y ago
    >Yeah, this is a very astute observation. isn't it just repeating the definition/use of debt which is why "technical debt" was called that in the first place?
    - marginalia_nu 2y ago
      In many cases, points of view obvious to the point of childlike can be easily overlooked and very helpful.
bigstrat2003 2y ago
> Author isn’t wrong per se, but code purity isn’t always a worthwhile goal, and needs to be balanced by the needs of the business. I would phrase this slightly differently: code purity is always a worthy goal, but it's not always an attainable goal. As you said, sometimes the needs of the business have to get in the way even though it is a worthy goal.
- mewpmewp2 2y ago
  It is a potentially misleading to think of it as a goal in terms of raw calculations. If we parallelize it to debt should it be your goal to have 0 debt and why? Shouldn't you first consider what is the interest rate of that debt and what do you gain by having this debt as opposed to not having it? If debt has 0% interest, and you don't have limit on debt, why not just keep taking debt? What if debt has negative interest? The goal should be to determine what is the optimal approach after considering all those factors and then take those approaches. Some people have principles that they don't want to owe anything to anyone, but this will make them take suboptimal decisions. They assign this emotional value to something that is actually an arbitrary concept.
- deleted 2y ago
  [deleted]
tdeck 2y ago
Another way to put it is that those colleagues are 4 teams away and 2 promos ahead before anyone has worked out exactly what went wrong and whose fault it was.

by dahdum 2y ago

freefaler 2y ago

Indeed, my own experience in my several companies confirms this. Yes, code quality is important, but we write code to solve a problem for the paying customer. If we can't solve it on time and on budget it doesn't matter how well it has been written. If you survive long enough you'll refactor the parts that are important. Also some parts are more important than other, everything with money calculation and potential data loss should be written more carefully.

Spivak 2y ago
I've always called this "good problems to have." If you're at the point where your slapped together solution doesn't cut it anymore then it means you're successful enough to actually need better. Don't use the solutions to hard problems when you don't have hard problems yet. Because they're making trade-offs to meet constraints that you're not under. Ranch dressing at the grocery store has to be shelf stable and they make a bunch of compromises to get it to that point. The ranch dressing you make it home can be better easily by just ignoring those constraints.
f819934580bd48f 2y ago
> potential data loss should be written more carefully. Doesn't this apply to any code that touches data intended to eventually be persisted? If so, IMO this applies to a huge portion of all software, I would guess more than half, because writes tend to be much more complex than reads IME.
- freefaler 2y ago
  Data loss usually occurs when you "migrate", "backup/restore", "upgrade" data. A stupid internal tool can wreak havoc because it's something non-customer facing with less stringent testing. The bugs on CRUD operations are usually ironed out early and can be limited to a small subset of data being lost. However a mingled migration script from one table to another is a really dangerous stuff but frequently it's treated as "internal tool". Floating point calculation and storage is also tricky and should be written/tested with greater care.

haswell 2y ago

> I’ve pushed some trash tier code over the years because it worked just well enough to drive growth/revenue With all respect, this summarizes everything I’ve come to hate about our industry over the years. I understand why this happens, and I’ve also been the person churning out crappy code at points in my career. But I think it also highlights how backwards the incentives have become, and we’re constantly seeing the real world impact playing out as the next zero day, the next botnet, the next Boeing scandal, etc. I’m not saying there’s never a place for bad-but-working code, but I’m increasingly convinced it never belongs in customer facing products, and that we have a major task ahead of us collectively to correct the mindset behind this and fix the incentive structure that enables this. Software runs the world now, and a frighteningly large number of software companies do not take their position of power seriously.

bschmidt1 2y ago
Is code more like poetry or more like a recipe? If the former, then yes we should be allowed the time and space to craft the highest syntactic art imaginable. But if it's the latter, it should just be quick, correct, readable, and extensible. If it's art - how dare you ruin my masterpiece? If it's business - we had a solution deployed for the customer in less than an hour. If syntax (poetry) is your #1 take your time. If money is your #1 you wouldn't call it "crappy code" at all. Even code that is not as performant as it could be is only "crappy" if it's affecting the bottom line (which it often does). But so-called bad code that is yielding higher profits, hard to call crappy.
- OrigamiPastrami 2y ago
  > If it's business - we had a solution deployed for the customer in less than an hour. Boeing was good at finding cheaper solutions to business problems as well. In the end it's society that suffers for our tolerance of late stage capitalism. There is no "right" answer to this. But tolerating crappy engineering because it's cost effective seems like an admission of defeat to people that actually want to make things better. It's not so much letting perfect be the enemy of good enough; it's more about the steady decline in quality because that's what we incentivize.

fidotron 2y ago

A former colleague of mine had a good way to describe it: technical debt is like financial debt, too much will kill you but if you don’t have any you will be outgunned by those that do. The trick is how to manage tech debt properly, and the widespread scrum fake-agile in use provides no means for ever tackling tech debt once taken on. This is one reason for the explosion in SRE teams.

marginalia_nu 2y ago
> A former colleague of mine had a good way to describe it: technical debt is like financial debt, too much will kill you but if you don’t have any you will be outgunned by those that do. Yeah, this is a very astute observation. It's also worth noting that the cost of technical debt is higher for larger organizations. Refactoring is very cheap when you're just one or a few people, but prohibitively expensive to the point of impossible when working in a much larger organization. I think it's generally a bad idea to write code to large-organization standards when you're working alone. It makes your process much more rigid than it needs to be. The great benefit of flying solo or with a small team is exactly how nimble you can be, the small cost of re-writes and even throwing stuff away.
- fsckboy 2y ago
  >Yeah, this is a very astute observation. isn't it just repeating the definition/use of debt which is why "technical debt" was called that in the first place?
  - marginalia_nu 2y ago
    In many cases, points of view obvious to the point of childlike can be easily overlooked and very helpful.

bigstrat2003 2y ago

> Author isn’t wrong per se, but code purity isn’t always a worthwhile goal, and needs to be balanced by the needs of the business. I would phrase this slightly differently: code purity is always a worthy goal, but it's not always an attainable goal. As you said, sometimes the needs of the business have to get in the way even though it is a worthy goal.

mewpmewp2 2y ago
It is a potentially misleading to think of it as a goal in terms of raw calculations. If we parallelize it to debt should it be your goal to have 0 debt and why? Shouldn't you first consider what is the interest rate of that debt and what do you gain by having this debt as opposed to not having it? If debt has 0% interest, and you don't have limit on debt, why not just keep taking debt? What if debt has negative interest? The goal should be to determine what is the optimal approach after considering all those factors and then take those approaches. Some people have principles that they don't want to owe anything to anyone, but this will make them take suboptimal decisions. They assign this emotional value to something that is actually an arbitrary concept.
deleted 2y ago
[deleted]

tdeck 2y ago

Another way to put it is that those colleagues are 4 teams away and 2 promos ahead before anyone has worked out exactly what went wrong and whose fault it was.