There are no bosses at Valve and they have a stack ranking system deciding how much money you make.
This means people there don't do unglamorous things like maintenance and stability fixes.
This means people there don't do unglamorous things like maintenance and stability fixes.
In practice, makers are different people from polishers, and Valve's system of hiring the "best" (people with impressive CVs) and salaries based on stack ranking means there is a huge bias towards makers (Who brought the company more money? the person who helped roll out dota2 or the person who fixed edge cases in the steam client?).
Many of Valve's products are full of bugs that don't get fixed for years. And since they only hire the "best", they don't have any testers. Many times patches are released that cause servers to crash within seconds (tf2 falling damage crash). And sometimes they release them on Friday which means it doesn't get fixed until Monday (Overflow error writing string table baseline crash). These patches were also mandatory.
Edit: though, to contradict myself, this is still as gameable as all hell if you do something silly like connecting it to reward and punishment.
We're into No True Scotsman territory here.
GOOD programmers know a lot of things. Put them in an environment that saps their initiative and they do 1 of 3 things: Leave, succumb or adapt.
The only thing that works is deliberately cultivating a culture where driving out the old bads is as important as creating the new goods.
Put another way: for self-direction to work, the culture needs to rank improvements as highly as novelty. Possibly higher.
Which it never does. At least, I have yet to experience or hear of a (software) engineering culture in which that's true.
I'm not sure if cultures like Toyota or the Nuclear Navy can be considered under this heading, as they mostly worked at a procedural-improvement level, rather than a product-improvement level.
This means people there don't do unglamorous things like maintenance and stability fixes.
How to create an incentive for this kind of work is an interesting problem, and I don't know enough about Valve to know if they've solved it.
I will say that the alternative is more dysfunctional. Closed-allocation, corporate alternative: some number of people are staffed on the ugly, career-damaging maintenance projects. The good ones either find a way to play the politics and move, or they quit, the bad ones stay. The end result is that the maintenance work is done by incompetents who don't care. This is a big part of why most legacy code only gets worse over time: the maintenance work is given to people who don't have the clout to do anything else, not to people who care enough about the health of the project to do it well.