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.
Subscribe to:
Post Comments (Atom)
4 comments:
Excellent post. The biggest problem I have with morale is that you can say stuff like "Have integrity", "Listen to your developers", or "Respond to issues up-front", but there is an entire aspect of practical application which is hard (if not impossible) to communicate. I wanted to keep my post practically-focused, but I just stalled out on that "morale" issue. So it's good to see other people picking up the ball.
My experience is that coder's complaints about code are less important than coder's comments on other issues. Developers are used to crappy code, and will take the time they need to fix it up -- but they feel helpless when it comes to business stuff. That's where the tech lead and PM can really earn their keep.
For instance, at my current workplace, we've got most of the developers along a single big island. A few of the developers are located on their own island, which (developers report) keeps those people out of the general loop, and makes it hard to get rapid feedback, reduces the amount they pair program, etc., etc. And we like those developers, so it would be nice if they sat with the rest of us.
And we had a few seats on the island that were pretty much always vacated: they were being used by the Agile coach and PM, who are (by their own admission) in meetings 8 hours a day.
So, the developers say, let's move those developers into those island seats.
When the coach and PM ended up *not* moving people in, and even moved the really useful business person away from the island, it really hurt morale. Developers felt like they weren't listened to, and so the retrospectives became a lot more reserved.
That was a bit of a vent on my part, but it's also a good what-not-to-do example.
"My experience is that coder's complaints about code are less important than coder's comments on other issues. Developers are used to crappy code, and will take the time they need to fix it up"
My situation is a little different in that the coders are not provided the time to 'fix it up' and as such feel that their issues are not being addressed. Just another take on the theme.
Communication is important like you say - and your situation goes to show how 'PHYSICAL' layout can effect it. I guess I would put forth the question "Are there any technical communications tools that help to alleviate the loss in communication felt by the small team off by themselves physically."
I find that even in those physical separation situations, that if there are a wide variety of communications tools available to the developers, they will work around the 'gap' in many and varied ways on their own. The problem is in getting IT dept's to allow a WIDE variety and let the teams choose.
I find that even in those physical separation situations, that if there are a wide variety of communications tools available to the developers, they will work around the 'gap' in many and varied ways on their own. The problem is in getting IT dept's to allow a WIDE variety and let the teams choose.
We use JIRA and Rally as communication tools, as well as a daily scrum, and that's working out pretty well.
The physical location problem isn't really that severe. It's just that the team bonded pretty close, and there's a culture change when you can't throw a koosh ball at the whole team.
My original post for whatever reason found its way to /dev/null, so as such I'm going to post a much shorter version for the sake of time.
In my few positions as CTO/Senior Developer, I always found that the best way to keep morale up was to treat my staff as equals. It proved to be a hard dynamic to keep at times due to some of the systems or corporate procedures that I sadly had to enforce/implement.
Overall I found that as long as everyone was given enough freedom and comfort, that they would produce at their best output levels. They were told quite succinctly that if their projects were completed within the reasonable time allotted, then there would be continual freedoms available to them.
I found that not only did this produce a happier, more productive environment, it also meant that I didn't need to push anyone to meet their deadlines, they were self monitoring. Only when certain draconian decisions came down from our (new at the time) corporate overlords (after new ownership came on board), did the morale start to drop, and everyone ultimately jumped ship before it crashed and burned due to poor corporate decision making.
There was really nothing that I nor anyone else in my department could do to counter such blows to the entire team's mindset and morale.
Eric
http://www.codedevl.com
Post a Comment