Or maybe programmer B is trying to maintain a monolith of pasta for which there is no documentation, the original programmer has long since left the company, no one is entirely sure what the business rules of the program are actually supposed to be, there are no tests, and you don't have time to actually read and understand all 100k lines of code.

Management just needs this one little feature tweaked, so you dive in to where you think that needs to go, make the new thing happen while absolutely changing as little as possible because god help us if anything breaks.

Now imagine that you're not the second or third person to be responsible for this, but maybe the tenth or so, and it's been going on for decades. And the last person to work on it was really new to this language and didn't understand its idioms very well, or vice Versace, and you don't understand the language very well.

I greatly enjoy these conversations about code quality and maintainability, but I've encountered it more than once where business constraints don't allow you to even start to think about these issues. You have no choice but to respect the abstraction you inherit because your job is to get in, get out, and pray you didn't break some edge case that no one would ever think of.

Or maybe I'm just an amateur/novice.

You can always chose to change the surrounding code whenever you are adding something to an existing mess, to make a bit less mess. I have heard excuses about not being given time to do it from the management many times before, but the fact is that you are the one who deals with the code, you need to make the decision. If you are not comfortable doing some change, you are the one who needs to be writing the tests or making sure you understand the code. It's not some kind of separate task. It's essential for doing your job right, so you should not expect extra time allocated for it.

Just adding your small change without touching the rest of the application is usually the easiest way, though, so most people just do that instead.

The best rule I have heard is to always leave any code you touch in a better state than you found it.

I don't think this is a realistic attitude. I've gotten my fingers burned more than once by trying to take this approach.

The problem with web applications is that they are not self-contained. You don't necessarily know who or what is calling what or how for some legacy applications.

I can agree with the concept of improving code as you see it, but changing the abstraction--the topic of conversation here--cannot be done willy-nilly for any non-trivial app. You have to dig up all the people are, or were, or will be counting on that abstraction, and that's a challenging thing to do sometimes.

And then you have to provide a business reason for you to allocate the time necessary to go read those 100k lines of code and understand them or write tests for them. And you tell your boss this is a mess and needs serious work, and he says, "Dude, this isn't rocket science, and we're going to burn this whole thing down in a few years anyway, and all I need you to do is add this one button in this edge case and don't break our standalone desktop app that isn't going to get updated to understand this functionality."

You're idealism is admirable, and I don't disagree with it. But the reality of the world is that if you work for a company whose primary product is not software (hell, even sometimes when you do!) the priorities are about the business functionality, not about the state of the code or the right abstraction.

I just think it's a little disingenuous for people to have these conversations in a vacuum and attribute anything from malice to incompetence to a person who takes a different approach.

Maybe I am being idealistic, but I think the sentiment in the discussion concerns not only the ideal coding techniques themselves, but also the bigger picture of business needs. That is, if we took the approach of keeping code in somewhat decent shape, we would end up, in the long run, producing the whole system more efficiently, and reducing the TCO of the system for the user and the business.

I certainly hope that the discussion is not only about making the lives of the programmers easier.

>It might be due to lack of skill or experience, or maybe laziness, or lack of discipline, or some other negative attribute.

I think you might be committing the fundamental attribution error. )https://en.wikipedia.org/wiki/Fundamental_attribution_error

>the tendency for people to place an undue emphasis on internal characteristics (personality) to explain someone else's behavior in a given situation rather than considering the situation's external factors.

Rather than considering external issues like time crunch, management pressure, or too-high a workload, or anything else it's much easier to just assume everyone else is a lazy and shitty programmer.

> This isn't about honor. It's simply bad programmer behavior. It might be due to lack of skill or experience, or maybe laziness, or lack of discipline, or some other negative attribute.

Time pressure may also be an issue.

Or, what if the system is only for prototyping, and later turns out to be needed for production (a management decision)?

Then management should be made aware that they're incurring technical debt by taking that decision. It can be worth compromising code quality for short-term goals on occasion, but you should do it with your eyes open.

I agree. I think Sandi was just being generous and forgiving, for the sake of not getting sidetracked. The fact of the matter though is that those "small" refactors do take place quite commonly. Out of laziness or else, and start a slow spiral...