Normal people don't understand this concept; they believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet.
- The Dilbert Principle (1996)

"If it ain't broke, don't fix it - unless the customer's paying."

Rule I've never learned and main reason why I don't have enough money despite 25+ years of experience.

*squirming in bed*
If it ain't broke don't fix it.. If it ain't broke don-WHAT THE FUCK IS "payment.needed2"??
Calm down, it's just some bad code but it works, you didn't write it, it's not your probl-WHY THE FUCK DO THE IF STATEMENTS HAVE SO MANY DUPLICATED LINES??

Sleep. Just sleep.

Why would someone in their right mind change a piece of code that was working fine (and it wasn't a complete mumbo jumbo in styling, logic, transparency, was in line with how the project was coded etc..) to use dapper just to call a stored procedure?! Dafaq is wrong with people!?
Or is it just me & I'm overreactig again?!
I hate when people add more stuff to projects that are already overbloated with fw/techologies to do something so trivial.. like adding 6827646 js fw so you can use one function in each (or are simply still there because they didn't know how to use it and left it in project) which could easily be achieved with our own fw we use...wtf?! O.o
// me cringing, cussing etc..

"If it ain't broke, don't fix it
I gave it to you straight don't mix it"...

Since when did DMX take on Programming?

How I decide on whether to update drivers: "If it ain't broke, don't fix it"

If it ain't broke, don't fix it

I really like my position as the head of my department. But I am most definitely hitting walls(and in some way breaking them) concerning the way the CTO(my direct boss) deals with a lot of the things that his management team wants to do.

For example, the previous manager could only do so much in terms of directing a software team since she did not have a formal background in computer science or engineering, thus the developers that she had would tell her the different deals with many things and she would have to take their word for it. Nothing necessarily bad with this, but it just meant that a lot of things could have gone smoother had she the knowledge to fix said items. Whenever she would try to use resources(dev time or such) the CTO will resort to the all powerful manthra of "if it ain't broke don't fix it!".

but it was about more than fixing things that were breaking, our internal services and admin boards were built using all of the WRONG proper development practices, it feels as if they took the book of best practices.....and said fuck it and did whatever the fuck they wanted. It is the worst PHP/Java/JS code I have ever seen in my entire life and the reason why even though I do not concur with it I will always understand the dislike from other developers. Our services look like something that came out from the 90s, no style, no engineering concepts in place, no versioning no testing NADA zip(these are all web based services)

One in particular, it was an admin board used internally to let students evaluate their professors, the entire app is shit, and it was broken, for some UNGODLY reason, the original dev decided to use some weird external libraries he got from some blog somewhere and as such something that would take about 5 or 6 files is now a mess with over 200 php/js files all over the fucking place. The CTO insisted on fixing them, they were all broken, and I continuously told him that redesigning the application would be faster.

Mofo fought me on it, and in the end I did what I wanted and rebuilt the app.

It took me one afternoon. One fucking afternoon, over possibly 2 weeks of fixing it.

See, I am not one to just do whatever he pleases, but I am firm in my belief that if I know a better way I will do it and save precious time. The dude had to agree with me on this and promised to consider this shit on other items that will undoubtedly come up. He was lying out of his ass but oh well..........

W

If it ain't broke, don't fix it!

Context:
At work, I code primarily with Java.

I'm a big believer in the mantra, "if it ain't broke, don't fix it", but I find myself conflicted with that when I can see how much of an improvement it would be to use a different language for some of the simple pieces in our integration.

Question:
When should one start considering other languages for your team? And if you choose other options, how do you do it in such a way where you don't end up building a chimera of an integration?

Worked on two (small) errors for about half my day. I've had them before but fuck I've never spend more than an hour on one. Decided to stop and go for a walk and game a bit after.

Came back today and instead of opening my code in VS Code I opened it in ST3 and I went through the errors again and I fixed it. I tried doing the same on VS Code but it didn't work just like yesterday.

Now, I've only had posititve experiences with VS Code and I really like, but what the actual fuck. Has anyone experienced this before and are there solutions or ways to prevent this? What is the cause anyway?

Also would appreciate some suggestions for code editors, love ST3 but I wanna try something new (I know, if it ain't broke don't fix it, got me)

Started a new project for .NET core. Spent the last 2 hours creating a new solution and trying to "make a great solution structure this time"...

Ended up with the same project structure of my previous projects.

If it ain't broke, don't fix it I suppose.