Another mismatch of developers and the business that employs them can be in software quality.
“Good enough” vs “Great” code.
Obviously developers vary, but many get frustrated because their personal standards for quality code are higher than the business that employs them. They can even feel like they have to “trick” their managers to get time to do it “right”. In the businesses eyes “if a user doesn’t think its broken, don’t fix it. Get back to sell-able features.”
Developers on the other hand see an accumulating pile of code. Stuff done two years ago is bound to have problems or be weaker than the more recent stuff.
One cost of not re-factoring is in greater maintenance costs and bug fixing. This is true if the quality is bad and it the product is being constantly stretched. However much software chugs along, does its limited job and is not frequently extended. Doing a re-factor of that code, even if the code is bad can actually introduce more bugs.
But for the developer it seems like a ticking time bomb. More than that, code reviews or having other developers poke around in that code to fix or extend it can actually be embarrassing. (Trust me, you want to have the type of developers that might be embarassed if people are looking at their “bad code”.)
So what can be done when a business wants to move on, but the developer wants to perfect or re-factor. In my experience its best to be explicit and name certain pieces of code “core” and others “secondary.” Core code is the essential IP of the group and will be a part of the overall product line as long as there is a product line.
To put it simply, core code gets the full treatment and the secondary code does not.
How does the separation help the problem of quality mis-match?
Well first it helps a business acknowledge and embrace the improvements in its core technologies. It makes it an investment rather than just engineers off spinning their wheels. For developers, it helps them accept that not every part of the code needs to be perfect. It helps focus them on the important parts and helps them accept that portions of their work are “throw-away” experiments. No need to be embarrassed about throw-away code and its not surprising when someone has to make some tweaks to keep it running now and then.
This designation of “core” and “secondary” code fits well with the suggestions for test grounds for new technologies I discussed previously. Its an important concept. There is ususally an implied separation of whats critical and whats not. I strongly suggest you formalize it and are explicit about exactly what that means.