4 ms·

> 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

> 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.
- ChrisMarshallNY 2y ago
  I have found that "it depends" is an almost universal solvent for all technical quandaries. I have found in my experience (and I have a lot of that), that the search for "One Solution To Rule Them All" is a snipe hunt. You can't get there from here. It always (in my experience) comes down to context[s]. That "[s]" is important. There's the current context, and then, there is the future context. You survived your baptism in fire to live to keep delivering software. That's great. It's crap software that got you here. Time to rewrite it, so we now have software with a future Right? OK? That's what we'll do...right? Oh, for Cthulhu's sake, what do you mean we need to keep building on our foundation of sand? Congratulations. You now not only have technical debt; you have technical bankruptcy, coming down the road. Better sell the company fast, before the bomb goes off...
  - Viliam1234 2y ago
    The mythical "later" never happens. Today we need to get version 1.0 to the market ASAP. Tomorrow we will need to get version 2.0 to the market ASAP. Etc. It's like people who promise that they will stop smoking later. Twenty years later, they usually still smoke. Twenty years later, if the software still exists, all the technical debt tickets will probably still be in the backlog.
- cjfd 2y ago
  It is you who starts to talk about 'art' en 'poetry' but these words do not come from what you are reacting to. One thing you seem to assume is that the 'crappy code' works and therefore the concerns about its crappiness must be about irrelevant things like 'art' or 'poetry'. However, the working of what I would consider crappy code is generally highly tenuous. There has not been found a bug, YET...., but one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs that are just waiting for the right circumstances to occur in practice. Also when bad code is changed, this is a much riskier affair because it is difficult to be sure that no unwanted side-effects were introduced. There is a hypothesis that the crappy code was faster to write. At some point, this becomes false because one also has to spend time fixing the bugs. I would wager that this duration is measured in weeks, rather than months. From which it follows that the picking crappy code for speed is actually foolish and lowers profits for all but the most simple projects.
  - bschmidt1 2y ago
    > must be about irrelevant things like 'art' or 'poetry' If by "bad code" you mean something related to syntax, convention, or code that "might have bugs" (wtf), there is still a case it's actually "good code" if it's more readable, was a quicker solution that yields higher profits, is a less error prone approach to the larger management of the codebase albeit less performant etc. > one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs Sounds too superficial/judgmental and not evidence-based. If there is a bug there is a bug. Even perfectly written code to the best possible standard can still be code that does the wrong thing.
    - orwin 2y ago
      Poor architecture/design make code unmaintanable, or at least very expensive to maintain. I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works. How you handle your data is also very telling of the code quality. I'm not against the "write shit fast, fix later", it is in fact how i do my stuff, but once i have a functioning prototype and basic mocks, i then spend a long time in my models.xxx file because modeling data is like 30% of the job. I have an example of bad data modelling: your object (that is a data representation) have fields that in certain case will be empty and you know it. Some people will ignore them. In 90% of the cases, this is a mistake that will lead to mistake down the lane. If you can use discriminated unions and don't because "it's faster" (it takes literally 2 minutes to do), you are probably writing bad code. It's not about idiomatic or not following conventions (those help) or not typing your data, it's about bad modeling choices.
- andrepd 2y ago
  > so-called bad code that is yielding higher profits, hard to call crappy Missing the point of the person you're replying to entirely... Yes you can get higher profits with shittier code, just as you can by building shittier airplanes, cars, bridges, etc. The consequences being exploits, hacks, 737MAX, Ford Pinto, etc
  - bschmidt1 2y ago
    I think you missed the point that it wouldn't actually be shittier code in that case. Some ugly 4 space indented, wrong kind of loops, old Node version, mongo as the main db, no linter, callback hell SaaS platform in 1 file called "server.js" could still be more reliable and yield higher profits and sooner than your masterpiece in Rust.
    - andrepd 2y ago
      Yes, and then your user's personal details go on a darkweb leak. But who cares! You made bank and no law or liability will actually punish you for it, so what the hell.
      - bschmidt1 2y ago
        No need for a dark web, Twitter and GitHub have both leaked user passwords stored in plain text on their own platforms right here on the corporate web. Twitter who struggled to turn a profit (but not to pay its investors who became wildly rich off it) hired artists who chose technology like Ruby on Rails. They should have hired capitalists who breathed jQuery and ate pieces of sh*t like Active Record for breakfast
mihaaly 2y ago
Those shipping fast and lot write software not to use but to sell. Not for the user but for sales and marketing departments. And this is why software and programmers are not respected, rightfully so. Judged by their products. And software are crap (and then reasoned with vigour why crap is good by those having incentives in it). Much more time than not, the not is the exception nowadays. Those having too little resources (money) for their monumental ambition also ship fast. Also it is so f annoying. All those river of notifications about 'hey, brend new version, now!, stop everything and download right away or else!' is a great nuisance. Like if this was the center of the life of the user, to have the newest and prettiest and greatest new feature (or mostly fixup of f*ups) of the software used. Secret for developers: no one cares. They need a tool to do the thing, and that's it. Do it well, do it smooth, that's all that counts. Not the new versions. Please write it well in the first place instead of this endless tinkering and bugging the customer. Sipping too fast is some sort of premature ejaculation of the programmers' mind.
dyauspitr 2y ago
Well most places putting out code for the first time don’t have the luxury of spending the time to put out perfect code. The funding only lasts so long, you’re trying to outpace competitors, you end up getting continuous scope creep etc. Star Citizen is a great example of what happens when you want to get everything perfect before you release it, by the time you’re done someone else has eaten your lunch.
fabian2k 2y ago
One big problem is that you often don't know yet what you actually need, you only find that out when your software is in front of real users. So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs.
- haswell 2y ago
  The issue is that what often happens next is the thing that got cobbled together as a customer POC ends up in production. Most hardware goes through extensive validation and revision before tooling to manufacture and ship at scale. The software space hasn’t always (often has not) found the correct balance between low cost early iterations and a properly hardened customer-ready product. The temptation is strong to just call it ready because it’s always possible to patch it later. While I agree that finding this balance is a challenge, I don’t think that lowers the criticality of productionizing the code or the risk of using these early stage products that haven’t “grown up”.
- rekabis 2y ago
  > So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs. IME, the core foundation of the product should be built such that no more than ≈20% or so of the MVP is ejectable in this manner. Not that it can’t, but more importantly: that it doesn’t have to. An MVP should be so basic that the majority of it would be foundational to anything being built, and so would remain in part or in whole no matter what redirection is taken. This is not always possible, but for most ideas there is a core element that you can start with, even if usefulness won’t really be there without a lot more functionality. > you often don't know yet what you actually need, you only find that out when your software is in front of real users. Which is why an MVP should only ever be the absolute minimum viable product - so that as soon as it ends up in front of users, you can lurk in whatever user forum you stand up and advertise for the product (subreddit, etc.) and listen to what the users are saying. Some of them may inadvertently drop ideas that can make or break your product, and it’ll be things you never thought of. Being able to pivot on a dime is why an MVP is so vital to begin with.

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.
ChrisMarshallNY 2y ago
I have found that "it depends" is an almost universal solvent for all technical quandaries. I have found in my experience (and I have a lot of that), that the search for "One Solution To Rule Them All" is a snipe hunt. You can't get there from here. It always (in my experience) comes down to context[s]. That "[s]" is important. There's the current context, and then, there is the future context. You survived your baptism in fire to live to keep delivering software. That's great. It's crap software that got you here. Time to rewrite it, so we now have software with a future Right? OK? That's what we'll do...right? Oh, for Cthulhu's sake, what do you mean we need to keep building on our foundation of sand? Congratulations. You now not only have technical debt; you have technical bankruptcy, coming down the road. Better sell the company fast, before the bomb goes off...
- Viliam1234 2y ago
  The mythical "later" never happens. Today we need to get version 1.0 to the market ASAP. Tomorrow we will need to get version 2.0 to the market ASAP. Etc. It's like people who promise that they will stop smoking later. Twenty years later, they usually still smoke. Twenty years later, if the software still exists, all the technical debt tickets will probably still be in the backlog.
cjfd 2y ago
It is you who starts to talk about 'art' en 'poetry' but these words do not come from what you are reacting to. One thing you seem to assume is that the 'crappy code' works and therefore the concerns about its crappiness must be about irrelevant things like 'art' or 'poetry'. However, the working of what I would consider crappy code is generally highly tenuous. There has not been found a bug, YET...., but one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs that are just waiting for the right circumstances to occur in practice. Also when bad code is changed, this is a much riskier affair because it is difficult to be sure that no unwanted side-effects were introduced. There is a hypothesis that the crappy code was faster to write. At some point, this becomes false because one also has to spend time fixing the bugs. I would wager that this duration is measured in weeks, rather than months. From which it follows that the picking crappy code for speed is actually foolish and lowers profits for all but the most simple projects.
- bschmidt1 2y ago
  > must be about irrelevant things like 'art' or 'poetry' If by "bad code" you mean something related to syntax, convention, or code that "might have bugs" (wtf), there is still a case it's actually "good code" if it's more readable, was a quicker solution that yields higher profits, is a less error prone approach to the larger management of the codebase albeit less performant etc. > one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs Sounds too superficial/judgmental and not evidence-based. If there is a bug there is a bug. Even perfectly written code to the best possible standard can still be code that does the wrong thing.
  - orwin 2y ago
    Poor architecture/design make code unmaintanable, or at least very expensive to maintain. I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works. How you handle your data is also very telling of the code quality. I'm not against the "write shit fast, fix later", it is in fact how i do my stuff, but once i have a functioning prototype and basic mocks, i then spend a long time in my models.xxx file because modeling data is like 30% of the job. I have an example of bad data modelling: your object (that is a data representation) have fields that in certain case will be empty and you know it. Some people will ignore them. In 90% of the cases, this is a mistake that will lead to mistake down the lane. If you can use discriminated unions and don't because "it's faster" (it takes literally 2 minutes to do), you are probably writing bad code. It's not about idiomatic or not following conventions (those help) or not typing your data, it's about bad modeling choices.
andrepd 2y ago
> so-called bad code that is yielding higher profits, hard to call crappy Missing the point of the person you're replying to entirely... Yes you can get higher profits with shittier code, just as you can by building shittier airplanes, cars, bridges, etc. The consequences being exploits, hacks, 737MAX, Ford Pinto, etc
- bschmidt1 2y ago
  I think you missed the point that it wouldn't actually be shittier code in that case. Some ugly 4 space indented, wrong kind of loops, old Node version, mongo as the main db, no linter, callback hell SaaS platform in 1 file called "server.js" could still be more reliable and yield higher profits and sooner than your masterpiece in Rust.
  - andrepd 2y ago
    Yes, and then your user's personal details go on a darkweb leak. But who cares! You made bank and no law or liability will actually punish you for it, so what the hell.
    - bschmidt1 2y ago
      No need for a dark web, Twitter and GitHub have both leaked user passwords stored in plain text on their own platforms right here on the corporate web. Twitter who struggled to turn a profit (but not to pay its investors who became wildly rich off it) hired artists who chose technology like Ruby on Rails. They should have hired capitalists who breathed jQuery and ate pieces of sh*t like Active Record for breakfast

mihaaly 2y ago

Those shipping fast and lot write software not to use but to sell. Not for the user but for sales and marketing departments. And this is why software and programmers are not respected, rightfully so. Judged by their products. And software are crap (and then reasoned with vigour why crap is good by those having incentives in it). Much more time than not, the not is the exception nowadays. Those having too little resources (money) for their monumental ambition also ship fast. Also it is so f annoying. All those river of notifications about 'hey, brend new version, now!, stop everything and download right away or else!' is a great nuisance. Like if this was the center of the life of the user, to have the newest and prettiest and greatest new feature (or mostly fixup of f*ups) of the software used. Secret for developers: no one cares. They need a tool to do the thing, and that's it. Do it well, do it smooth, that's all that counts. Not the new versions. Please write it well in the first place instead of this endless tinkering and bugging the customer. Sipping too fast is some sort of premature ejaculation of the programmers' mind.

dyauspitr 2y ago

Well most places putting out code for the first time don’t have the luxury of spending the time to put out perfect code. The funding only lasts so long, you’re trying to outpace competitors, you end up getting continuous scope creep etc. Star Citizen is a great example of what happens when you want to get everything perfect before you release it, by the time you’re done someone else has eaten your lunch.

fabian2k 2y ago

One big problem is that you often don't know yet what you actually need, you only find that out when your software is in front of real users. So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs.

haswell 2y ago
The issue is that what often happens next is the thing that got cobbled together as a customer POC ends up in production. Most hardware goes through extensive validation and revision before tooling to manufacture and ship at scale. The software space hasn’t always (often has not) found the correct balance between low cost early iterations and a properly hardened customer-ready product. The temptation is strong to just call it ready because it’s always possible to patch it later. While I agree that finding this balance is a challenge, I don’t think that lowers the criticality of productionizing the code or the risk of using these early stage products that haven’t “grown up”.
rekabis 2y ago
> So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs. IME, the core foundation of the product should be built such that no more than ≈20% or so of the MVP is ejectable in this manner. Not that it can’t, but more importantly: that it doesn’t have to. An MVP should be so basic that the majority of it would be foundational to anything being built, and so would remain in part or in whole no matter what redirection is taken. This is not always possible, but for most ideas there is a core element that you can start with, even if usefulness won’t really be there without a lot more functionality. > you often don't know yet what you actually need, you only find that out when your software is in front of real users. Which is why an MVP should only ever be the absolute minimum viable product - so that as soon as it ends up in front of users, you can lurk in whatever user forum you stand up and advertise for the product (subreddit, etc.) and listen to what the users are saying. Some of them may inadvertently drop ideas that can make or break your product, and it’ll be things you never thought of. Being able to pivot on a dime is why an MVP is so vital to begin with.