[maxxxxx]

I think it's a matter of attitude. Either you accept that there is value in keeping a code base reasonable or not. Maybe some metrics can help to make a point but any metric will be abused over time if used too religiously.

You are making a good point about people not being around long term. In my company there are departments with high turnover and they tend to go for quick victories that are often costly in the long term. At the time this becomes clear the manager who made the previous has already been promoted somewhere else and the next guy will make another quick decision to fix the previous problem. Then this guy gets promoted too and the cycle continues.

Technical debt is really only a problem if you think long term.

[stcredzero]

A good analogy for older management, which is disappearing as an extant object in the office, is that of the file room. Sometimes, you'll see a seeming "whiz kid" file clerk who seems to be far faster than normal, but it turns out that he's "faster" because he doesn't actually re-file and reorganize.

Refactoring is quite literally the same thing as re-filing and reorganizing physical files. Under the academic definition of refactoring, the "contents" (the functionality) is not changing. Only the organization is changing.

[Jtsummers]

A colleague and I developed a good routine for a while. He's a much faster programmer than me. But his code quality is usually much lower (not wrong, but often poorly structured and hard to maintain). He'd code fast, I'd code slow. Then I'd clean up his stuff while we waited for feedback on the system and he did other things. Refactoring work and the like, no meaningful (to an end user) changes.

This was effective. Except that management saw him as fast and so he kept getting more work, and completing it. But the quality wasn't there because no one went in behind him to keep it clean and tidy. Management never really saw the issue, they just thought the rest of us were bad programmers because we were so slow. We were slow because: 1) some of us (like me) work slowly; 2) the fast guy introduced a lot of technical debt (or we introduced it because we weren't given the cleanup time I used to have).

He's still a good programmer (in general), but without the support structure his products are far less useful than they same at first glance (due to the introduced technical debt).

[hinkley]

Having to work in and around very bad code slows everybody else down, we have a very prolific guy who creates his own jargon (inconsistently) and enjoys convolution like it’s an art form. Everybody else has to spend twice as long doing the most rudimentary features.

But management loves their heroes, so the people with high tolerance for complexity get promoted, and all the people I trust keep leaving...

[maxxxxx]

I have worked with people like that. They are really good for prototyping new stuff. But you definitely don't want their code go straight into a long term code base.

[minitoar]

Indeed, sort of like how not ever bathing is only a problem if you think long term.

[carapace]

To paraphrase Quentin Crisp, after the first few years the smell doesn't get any worse.

[maxxxxx]

In software it actually gets worse and worse and worse....

[carapace]

Oh I know. It's Quentin Crisp's joke, if you know who that is.

I worked for two years at a big corporation (mostly as an experiment, but also to prove that I could) on a huge and somewhat important internal project (meaning that we're were never going to be killed because we represented a thing that would save millions of dollars when it finally worked AND we had no external users that could abandon us, ours was a captive audience.)

> At the time this becomes clear the manager who made the previous has already been promoted somewhere else and the next guy will make another quick decision to fix the previous problem. Then this guy gets promoted too and the cycle continues.

Not only did I see that happen two or three times while I was there, but the project itself had been crapped out by some cowboy coder who stood up a demo, got some traction for it, and moved on to greater things. He had a rep as a Rockstar because of this project but if you actually looked at what he did (as I had to every day) it was a rickety un-designed P.O.S. that could barely function. It was a glorified spreadsheet basically, but of course not implemented on top of the in-house spreadsheet product. We rolled our own TableView... It also crashed on importing more than 25K (not M, K) records, which was one of the main reasons it had been started in the first place: the existing system it was meant to replace was slow on large ("large") datasets. The new system wasn't slow, it just crashed. This was progress.

But the money was good. Food too.

-----

edit, I started getting flashbacks to that job after writing the above. Hoo boy was that ever a shocking place to work. I feel like I was kidnapped by aliens for two years.

The software was a textbook case of the "Lava Flow" anti-pattern: http://antipatterns.com/lavaflow.htm It had at least five distinct waves of rewrites, all of which were left petrified in the code.

At one point the dispatch system was rewritten in this weird not-OOP, not-Aspect, not-Actor, style, during a wave of the "composition-not-inheritance" fad that comes and goes. I remember opening up one of the affect modules and thinking, "This is like Romulan code." It was so strange.