Client : We want to develop this particular software. While developing it, we will be following Agile methodology.

Developers: Sure.

After developer achieves few features and decides to give 1st Demo of the software to the client.

Client : Wtf is this? This is an incomplete software, there are bugs in it.

Developer : Yes, you point that out to me and I will solve them.

Client: What do you mean point them out for you l, couldn't you do it yourself?

Developer: As a standard method, we often do unit tests, but we are not testers and with a strict deadline to match, we are more on the core implementation then checking again and again for minor bugs.

Client : I thought it would be a full proof software without any bugs in the 1st demo.

Developer : Software development is a process. It's not straightforward, hence you only mentioned at the initial, it's agile.

Client : If that's so, let's make it not agile and make you rot in hell for the next few fays. Now you next time show me a demo with no bugs, great complicated features and we will not mention you our expectations, predict them by yourselves, and most importantly, here's an impractical strict deadline.

So I joined this financial institution back in Nov. Selling themselves as looking for a developer to code micro-services for a Spring based project and deploying on Cloud. I packed my stuff, drove and moved to the big city 3500 km away. New start in life I thought!
Turns out that micro-services code is an old outdated 20 year old JBoss code, that was ported over to Spring 10 years ago, then let to rot and fester into a giant undocumented Spaghetti code. Microservices? Forget about that. And whats worse? This code is responsible for processing thousands of transactions every month and is currently deployed in PROD. Now its your responsibility and now you have to get new features complied on the damn thing. Whats even worse? They made 4 replicas of that project with different functionalities and now you're responsible for all. Ma'am, this project needs serious refactoring, if not a total redesign/build. Nope! Not doing this! Now go work at it.
It took me 2-3 months just to wrap my mind around this thing and implement some form of working unit tests. I have to work on all that code base by myself and deliver all by myself! naturally, I was delayed in my delivery but I finally managed to deliver.
Time for relief I thought! I wont be looking at this for a while. So they assign me the next project: Automate environment sync between PROD and QA server that is manually done so far. Easy beans right? And surely enough, the automation process is simple and straightforward...except it isnt! Why? Because I am not allowed access to the user Ids and 3rd party software used in the sync process. Database and Data WareHouse data manipulation part is same story too. I ask for access and I get denied over and over again. I try to think of workarounds and I managed to do two using jenkins pipeline and local scripts. But those processes that need 3rd party software access? I cannot do anything! How am I supposed to automate job schedule import on autosys when I DONT HAVE ACCESS!! But noo! I must think of plan B! There is no plan B! Rather than thinking of workarounds, how about getting your access privileges right and get it right the first time!!
They pay relatively well but damn, you will lose your sanity as a programmer.
God, oh god, please bless me with a better job soon so I can escape this programming hell hole.
I will never work in finance again. I don't recommend it, unless you're on the tail end of your career and you want something stable & don't give a damn about proper software engineering principles anymore.

Code fuckup day or what?! After two weeks where I wasn't on my project and a co-worker handled it, I came back to my project and reviewed what he had done so far.
Me: "I don't understand how this new code part here can work?"
Him: "Uhm, actually, it doesn't, somehow."
Me: "..."
Then he had checked in his stuff with spaces while the whole project is with tabs. And variables that were used in a different way, but still under the old name, now completely misleading. Bypassing existing infrastructure and defines with "just for this case" hacks. But the best was tracking higher level state by peeking into lower level data buffers, even pulling out their data definitions into global header files - instead of using proper states in the higher layer itself.
NOT! IN! MY! FUCKING! PROJECT!!!
So I spent the day cleaning up the shit to fight off software rot right in the beginning.

I really like this book on the basis of the philosophy overall, no this doesn’t solve all problems but it’s a good baseline of “guidelines/rules” to program by. Good metrics or goals to architect and design software projects high and low level projects.

Fight Software Rot
Avoid duplicate code
Write Flexible, dynamic, adaptable code
Not cargo cult programming and programming by coincidence.
Make robust code, contracts/asserts/exceptions
Test, Test, and TEST again and Continue testing.. this is a big one.. not so much meaning TDD.. but just testing in general never stop trying to break your software.. FIND the bugs.. you should want to find your bugs. Even after releasing code the field continue testing.

npm: "npm does not support Node.js v10.24.0; You should probably upgrade to a newer version"

Also npm: "Supported releases are the latest release of 4, 6, 7, 8, 9"

Uh...good to know this piece of software is still a dump where rejected code goes to rot.

Let's face it: I am and will always be a tinkerer. Yes, I know my ways around, I can sneak into legacy code bases easily and throw new stuff in there, I've seen software stacks. But scarcely sound design, really modular. Even from the cleverer, experienced ones. They can master more complexity, so they can handle more spaghetti. Some essay from the 80's had this grand idea to organically 'grow' software. That's how it looks like most of the times: cancerous, parasitic super fungi (armillaria). Yeah, we all know have to fight bit-rot and entropy, but it was all lost before already. We'll never get rid of legacy protocols, legacy code.
And even when we go green field, start a fresh. Yeah, take a great design, make everything new, after some months of throwing features and outer constraints at the thing, it's the same old mud again.
But we can still dream on: some day I will design great APIs, I will have great test coverage, documentation, UML design, autometed tests, fuzzing, memchecking, I'll work professionally, clean coder style.
Pfft forget it. Maybe change for consulting, because we'll continue to dream of the 'clean' code, so you can sell the next 'recipe', development method. It's like diets. As effective. For the one selling.

FIRE DRILL!!!!!

Customer who decided to deploy our system in the middle of their busiest time ... and kinda ad hoc-ed their ... human processes (not sure what to call it). Just to get by, and then sort of let things rot.

So last week they contact us and say "OMG some poor soul at this company was spending hours making spreadsheets to track what they were doing... and they keep fucking it up because it's nigh impossible to get right".

Real story, big shake up at the company, and someone said "lets look at our process" and they discovered "holy fuck we have this software but we're doing shit like it's the damned civil war".

This naturally raised questions about the competence of the folks we work with ... who chose our software, and thus our software.

So now we're flushing out all the stuff we asked the customer to figure out months ago that is usually done via a months long implementation / integration ... in a few days. Also ... I'm making some new things for them.

WEEEEEEEE

Granted, we're billing them like mad for this so no big deal really.

People responsible for closing threads on stackoverflow for "We don’t allow questions seeking recommendations for software libraries" should die and rot in hell forever.

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.
We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.
"The Pragmatic Programmer"