[manojlds]

I think the main thrust is respect the code and understand why it was there. Don't start with the possible initial feeling that a particular piece of code or guard is not needed. If you do find that it's not needed, remove it or fix it.

[Pawka]

I'll second manojlds's comment. If there is bad code/design decision on production - it not necessary means it was bad all the time. Software grows, requirements changes and it is very likely there is a reason why the code is as it is now. Even if it does not solve the problem efficiently today.

People also tend to forget human and business impact. The code might look different if there is 1 week or 4 weeks given for implementation. Timelines, pressure from management/stakeholders to deliver faster has impact to made solutions and implementations.

That is when respect is needed - having empathy to understand why this part of software looks like it is now.

[icebraining]

It's essentially the Chesterton's Fence principle.

[IanPBann]

This is very similar to Joel Spolsky's advice that you should never just chuck code out and and start from scratch.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[littleblah]

Yup. That was my inspiration, and sadly, I have been on the side as well where things started from scratch, and ended up blowing up couple of months later.