7 ms·

We encounter many rough drafts (yours) in production systems. If the original devs are still there, it is usually something along the lines of: I showed the rou

We encounter many rough drafts (yours) in production systems. If the original devs are still there, it is usually something along the lines of: I showed the rough draft to my manager, they flagged is as done and I was assigned to another task.

mattmanser 1y ago
Work with bad companies, be surprised by poor managers? Who is the "we" in this context, I assume an agency? So that's not a problem with this process itself. You're describing problems with managers, and problems with developers being unable to handle bad managers. Even putting aside the manager's incompetence, as a developer you can mitigate this easily in many different ways, here's a few: - Just don't show it to management - Deliberately make it obviously broken at certain steps - Take screen shots of it working and tell people "this is a mockup, I still have to do the hard work of wiring it up" It's all a balancing act of needing to get feedback from shareholders and managing expectation. If your management is bad, you need to put extra work into managing expectations. It's like the famous duck story, from Jeff Atwood (see jargon number 4), sometimes you have to manage your managers: https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/
- anonzzzies 1y ago
  Sure, but we actually thrive here; my company gets called in when systems are not functioning, badly broken, etc and they cannot fix it themselves (usually because the people who built it are gone for decades and they just kept it running with ductape for this time). We never stay for long, we just patch the system and deliver a report. But for figuring out what went wrong and writing the report, we find out how it got to be that way and it's always the same; they suck. Talking banks, hospitals, factories, it really doesn't matter; it's all garbage what gets written and 'TODO: will refactor later' is all over the place. We see many companies from the inside and let me tell you; HN is a lovely echo chamber that resembles nothing in the real world.
  - jimbokun 1y ago
    I think the main lesson here is that most entities shouldn't be writing serious software themselves, but purchase software from reputable software companies whenever possible. At least who to hold responsible or sue is clearer in that case.
croes 1y ago
This will get worse with AI
- anonzzzies 1y ago
  We already see it; the combination of job-hopping & AI are a perfect storm really. From launch to failure is definitely getting fast-tracked; few months ago we had yet another hospital system that just lost data; reading the code (no tests, no peer reviews; they don't use versioning) shows clear signs of LLMs; many files that do almost the same thing, many similar function names that do almost the same thing or actually the same thing, strange solutions to trivial problems, etc. The problem was that there was a script ran at startup which added an admin user, but if an admin user already exists, it truncates the table. No idea why, but it wasn't discovered earlier because after testing by the devs it was put live, devs left (contractors) and it just ran without issues until the ec2 instance needed maintenance by aws and was as such rebooted after which all users were gone. Good stuff. They paid around 150k for it; that is not a lot in our field but then to get this level of garbage is rather frightening. This was not life threatening, but I know if it was, it would not be better as you cannot make this crap up.
  - skeeter2020 1y ago
    And let us be very clear: this happened REGULARLY pre-AI, with long-lived systems adding contractors 12, 6 or less months over 20 or more years. Now we have AI that allows even faster iterations of this with even less conceptual integrity. The big problem: the decision makers(c-suite executives) never really understood what was happening before, so you can't expect them to see the root cause of the problem we're actively creating. This means it will not get the attention and resourcing needed - plus they'll be gone and on to the next one after taking a huge payday for slashing their R&D costs.
    - anonzzzies 1y ago
      Agreed.
- roane 1y ago
skeeter2020 1y ago
I see this an awful lot. Msot recently was presentation of hackathon projects with product managers & executives asking how much work was left to turn them into production features. It's pretty obvious how their brains are spinning.

mattmanser 1y ago

Work with bad companies, be surprised by poor managers? Who is the "we" in this context, I assume an agency? So that's not a problem with this process itself. You're describing problems with managers, and problems with developers being unable to handle bad managers. Even putting aside the manager's incompetence, as a developer you can mitigate this easily in many different ways, here's a few: - Just don't show it to management - Deliberately make it obviously broken at certain steps - Take screen shots of it working and tell people "this is a mockup, I still have to do the hard work of wiring it up" It's all a balancing act of needing to get feedback from shareholders and managing expectation. If your management is bad, you need to put extra work into managing expectations. It's like the famous duck story, from Jeff Atwood (see jargon number 4), sometimes you have to manage your managers: https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/

anonzzzies 1y ago
Sure, but we actually thrive here; my company gets called in when systems are not functioning, badly broken, etc and they cannot fix it themselves (usually because the people who built it are gone for decades and they just kept it running with ductape for this time). We never stay for long, we just patch the system and deliver a report. But for figuring out what went wrong and writing the report, we find out how it got to be that way and it's always the same; they suck. Talking banks, hospitals, factories, it really doesn't matter; it's all garbage what gets written and 'TODO: will refactor later' is all over the place. We see many companies from the inside and let me tell you; HN is a lovely echo chamber that resembles nothing in the real world.
- jimbokun 1y ago
  I think the main lesson here is that most entities shouldn't be writing serious software themselves, but purchase software from reputable software companies whenever possible. At least who to hold responsible or sue is clearer in that case.

croes 1y ago

This will get worse with AI

anonzzzies 1y ago
We already see it; the combination of job-hopping & AI are a perfect storm really. From launch to failure is definitely getting fast-tracked; few months ago we had yet another hospital system that just lost data; reading the code (no tests, no peer reviews; they don't use versioning) shows clear signs of LLMs; many files that do almost the same thing, many similar function names that do almost the same thing or actually the same thing, strange solutions to trivial problems, etc. The problem was that there was a script ran at startup which added an admin user, but if an admin user already exists, it truncates the table. No idea why, but it wasn't discovered earlier because after testing by the devs it was put live, devs left (contractors) and it just ran without issues until the ec2 instance needed maintenance by aws and was as such rebooted after which all users were gone. Good stuff. They paid around 150k for it; that is not a lot in our field but then to get this level of garbage is rather frightening. This was not life threatening, but I know if it was, it would not be better as you cannot make this crap up.
- skeeter2020 1y ago
  And let us be very clear: this happened REGULARLY pre-AI, with long-lived systems adding contractors 12, 6 or less months over 20 or more years. Now we have AI that allows even faster iterations of this with even less conceptual integrity. The big problem: the decision makers(c-suite executives) never really understood what was happening before, so you can't expect them to see the root cause of the problem we're actively creating. This means it will not get the attention and resourcing needed - plus they'll be gone and on to the next one after taking a huge payday for slashing their R&D costs.
  - anonzzzies 1y ago
    Agreed.
roane 1y ago

skeeter2020 1y ago

I see this an awful lot. Msot recently was presentation of hackathon projects with product managers & executives asking how much work was left to turn them into production features. It's pretty obvious how their brains are spinning.