In a follow up post to Brian Hurt's post on the Second Derivative of coding (Use and Re-Use). Robert Fischer expands on the same issue and has some wonderful additional thoughts from his own experiences with this same topic. The article does leave a large unanswered question at the bottom that I wanted to take a stab at answering, that is, how do you keep developer morale at a given organization high? Robert states that coders with high morale will be more communicative and more effective writing better code - the type of code that can be re-used, the type of code that will increase the speed of the team to get things done. The type of code that accelerates the team as a whole.
I have to agree with his end points. Coders that have a high morale tend to be like he describes, they want to help everyone go faster and more importantly they want to solve problems or speed bumps that they see getting in the way of going faster. The question of course is how do you keep your coders looking bright and shiny with a glossy sheen to their coats?
My simple answer to this question is: Listen and respond to their issues.
Lets assume for a second that you have done a reasonably good job at hiring some great coders. They may not all be spectacular but they are certainly a cut above. These people have been working for you for some time now and have started to provide feed back to manager(s) about what issues they are running into in the code. They are providing feedback about what happens when they attempt to solve business issues by developing functionality and the road blocks in the code they run into. The items that they bring up might range from something as simple as code organization to something as complex as how some 20 class files make up this bit of business functionality that could have been done in 10 classes with fewer code smells. What counts is that these complaints are HEARD in some way (meaning there has to be a way for the developers to attempt to address these problems both as a group and as individuals). If the comments go ignored and there is no time to address the issues, then morale suffers as does the code - because you start to fall into the negative acceleration phase of your second derivative. If no one is listening and ADDRESSING the issues over time the code is harder to maintain, harder to deal with and functionality is harder to implement taking a longer period of development. It turns into a cascade failure.
Coder morale is a hard thing only if you make it hard. Keeping your coders happy should be easy - it should be as easy as listening and addressing the issues they raise. Some of these issues may take a long time to address but as long as progress toward resolution can be seen most people will be more then satisfied to know that things are moving forward... the issues are getting resolved and importantly they are getting listened to.