But you should probably touch it before all the dependencies are outdated. And before everyone who understands how to work with it has left. Especially if it happens to be core to the business.

:)

Absolutely untrue. Keep your shit up to date. If you have time, simplify code.

looks at the startup scripts I just took from a 2h runtime to 15m

Guess I gotta revert those changes.

Well over a decade ago I remember a coworker would just go through the codebase and add his own coding style.

Instead of if (predicate) {

He would do if ( predicate )

I would always ask why he did it and he said, "well we don't have any coding standards so I'm going to do it" ... I replied, "there's things like unwritten rules and sticking to whatever's in the codebase makes it easy". I told the seniors and they chose not to do anything (everyone just merged into trunk) and they just left him for a while.

Then he turned rewrote built-in logical functions in code like this: if (predicate || predicate) {

Into code like this: if ( or( predicate, predicate ) ) {

This was C# and there was no Prettier back then.

Also, he would private every constructor and then create a static factory method.

Eventually the seniors told him to knock it off. All I said was that I initially tried telling them weeks ahead of time and now we got a mess on our hands.

That's a good way of maximizing technical debt.

This is actually not a good advice, from my experience. If we don't monitor, refactor, or improve the code, the software will rot, sooner or later. "Don't touch" doesn't mean we don't ever think about the code, but we make the conscious choice not to modify it.

Yeah, I've worked with the leave it alone types. What do you get in return? Components of your system which haven't been updated in the last 20 years and still run .NET 3.5. They obviously never stopped working, but you have security concerns, worse performance (didn't matter much in that case) and when you actually need to touch them you're fucked.

Why? Because updating takes a lot of time (as things break with every major revision) and on top of that if you then decide not to update (yeah, same coworker..) then you have to code around age old standards and run into bugs that you can't even find on Stack Overflow, because people didn't have to solve those in the last 20 years.

Or you do the right thing re-write or refactor, apply the latest practice add some tests to it. This way you won't have a black box anymore. Who knows there might be a hidden bug there that might be a huge security issue and could bite you back in the future.

i = 0x5f3759df - ( i >> 1 );

// what the fuck?

“That sign can’t stop me because I can’t read!”

I’m a big fan or refactoring and rewriting my code as often as I can. Not only does it keep my brain “on topic” but it allows me to make major improvements. Nothing will ever be perfect. Just try to leave it in a better state than it was before.

Fix it til it breaks.

flipside: it needs to be fixed but the only person who understands it is OOO

Its ok to touch up code. If you have lots of notes, on what its supposed to do.. I learned this the hardway.

No, we must rewrite it in this fancy new framework that came out last week.

(/s if not obvious)

if it ain't broke, don't fix it.

if it's still under-budget, break it carefully.

Update: bug fixes and some performance enhancement.

Don’t touch things unless you have a good reason to do so. And when you have a good reason, touch it exactly as much as you need - but never more.

If you know it works, you also know it well enough to touch it.

Almost everybody that says it is talking about something that doesn't work, and they don't know it.

And those two add-up to make any advice completely useless.

This week I am to propose two major redesigns to an external API and webpage on my rollercoaster of a project. Let's see this code monkey land a backflip :,)

Sorry I live by "if it ain't broke, I'll fix it"

Man this would have been great to have read a day ago.

... said no programmer, ever. Especially not after hearing about a cool new feature in their favorite language or library that was just added in the newest unstable version!

that's a challenge

I accept the challenge

Ice cold take: You don't have enough tests if you can't safely refactor on a whim.

A well-tested project should allow you to refactor arbitrarily. As long as all existing tests pass, rewritten code is at least functionally equivalent to the previous code. This allows for fearless performance rewrites, refactoring, and even complete redesigns of components.

In other words, the tests are more valuable than the code itself. The spec for the codebase proper should be defined by the tests. When the spec changes or grows, the tests should change or grow, and then the main codebase should be modified to pass all tests once again.

TL;DR TDD evades this issue entirely and is fantastic for larger and/or longer-term projects

I don't care, you're not to use static!

also applicable to "do not touch willie"

The best debugger is a good night sleep.

Lousy Smarch weather

In German we say:

„Ein funktionierendes System nie anfassen!“