[heartbeats]

It's intentionally built to be crap. If your requirements are constantly changing, you want to be able to turn on a dime. If you have "nicely architected" software, that's going to be a lot of work. If the "software" is just a folder of Python files and some shell scripts, adding in some hack to meet some business need is very quick work.

In mathematical terms, the ratio of A - the amount of hours spent writing the software to B - the amount of hours spent running the software is going to be very high. It doesn't make sense to spend two hours to fix a bug, if you can just spend ten seconds applying a workaround, unless you'll run it more than 720 times within its intended design lifespan.

[gorjusborg]

> the amount of hours spent writing the software to B - the amount of hours spent running the software is going to be very low

I agree on this point, the amount of time writing software is almost always going to be dwarfed by the maintenance period for software that makes it to production.

I've also seen businesses pay a lot of money software maintenance, but you seem to be implying that under-investment is a conscious choice. I would suggest that's not the main driver for software chaos.

The most common reason I've seen good software turn into an unmaintainable mess is knowledge loss / employee turnover over time. This usually results in a culture of fear around making changes to something that is poorly understood. When changes are made, they are done with incomplete understanding, and are consequently not in line with the original design choices.

Over time, even the maintainers move on. This continues until the whole thing is a complicated mess that nobody can understand, even the original author. That's when The Rewrite is suggested.

[heartbeats]

> the amount of time writing software is almost always going to be dwarfed by the maintenance period for software that makes it to production.

Oh sorry, I meant it the other way around!

So, I mean, I've seen this in scripts that I wrote to "quickly do some stuff".

1. Write the easiest possible implementation you can think of, just string together code in the REPL until it works, then put it all into a .py file

2. Some new need arises. Make the easiest possible change that causes it to work, like adding a new switch that completely changes the control flow.

3. Some new bug arises. Make the quickest possible change that causes it to work, like running the entire program in a while-true loop in case it crashes.

4. Continue along this manner until half of the code is commented-out garbage.

5. Rewrite.

There's no need to make it a thing of beauty, because it's easier to just scrap it and rewrite it. For the short term, making a "quick fix" is nearly always better, and for the long term, running a buggy piece of shit might still be preferable to spending good money to rewrite it.

(Also, the good stuff often already exists as open-source software, so it's only the hyper-specific stuff that's proprietary, and that will be closely tied to business needs.)

[gorjusborg]

I get what you were saying now... you were talking tooling, not product software.

I agree with your take on the tooling side. No need to gold-plate something that works in the narrow scope it was created for.