This is so funny. I once worked on a year long project. The aim was to reduce customer escalations for my client. Changed the architecture of an extremely complex software making sure no regressions occurred and all new features worked flawlessly. The software was released and no customer escalations. I was happy, but found no one else cared. A few months later, during a meeting with the client manager, I brought this point up. I was told that since I delivered an error-free software, people forgot about it and that is a good thing. I wad told that if I wanted to get noticed, I should firefight instead of writing bullet-proof software.
This is similar to all the fixed issues we solved for Y2K. When nothing happened then rather than saying 'well done to all who fixed the issues' it became 'that was a waste of time and overblown as nothing happened.' Sometimes I think they wished a plane fell from the sky due to a software bug so they could slam software developers for incompetence.
My take is that you don't get rewarded for it directly, but rather once you're finished, you can move on to the next thing without having to constantly firefight and squash bugs on the previous project. So ideally you can get a lot more done in a given half than someone who pushed out a pile of buggy spaghetti that they're now constantly having to deal with.
On the other hand, if you can ship something a few weeks faster that might have a few bugs, but the customer never notices, I can understand why a business would reward that.
True, but my experience is that managers are not so great at recognizing consistent good results but often remember someone coming through in a clutch situation. Because measuring developer performance is hard, the consistently good dev is often overshadowed by the one who put out fires (even if they were the firestarter).
