Tuesday, September 11, 2007

The Morale Morass

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.

Sunday, September 9, 2007

Factor/Refactor - get fast and stay there!

Something that I saw in two different posts recently got me thinking. The first post had to do with abbreviation and accidental complexity, the other was on Use and Reuse of code. The topics are intertwined and linked.

The commentary on Raganwald attempts to point out that just because something is brief it is not necessarily better and at the same time the reverse can also be true, that something verbose may not be easier to understand over all due to accidental complexity. Programming is about finding the balance between the two points. In other words the SNR (Signal to noise ratio) in ones code is an important factor. This leads to the second article on Use and Reuse of code.

I especially liked the commentary that Enfranchised Mind's Brian Hurt provided here, that the Use vs. Reuse of programming could be considered the Second Derivative of programming (remember back to all that calculus, the second derivative is acceleration). Stated in another way, that whats important in programming is the ability of a coder(s) to add new code faster and more efficiently in a constantly changing environment.

Why is this so important? What makes this idea of adding new code faster and more efficiently such an important topic to cover? Well, the reason that I have been finding it important lately wraps around to another fact of life - systems of things (programming software or otherwise) tend towards entropy and need attention to be held at their current state or improved in anyway. This plays out in the following fashion:

An existing system of code lends itself to doing certain things in certain ways. This way of doing things often represents the way in which the programmers 'thought' that certain bits of system code would be used in the short term. Those same programmers my have been forward thinking about needed changes or potential other uses but lets face it we are all not prognosticators and can not read the future. That being said at some point in the future the code is going to need to be modified to suffice some additional need. Now the question becomes how hard is it to suffice this new need given what currently exists. If it is hard to suffice this new need because the code is not structured in a way that allows its reuse then the coder is going to have to slow down and possibly implement a bunch of things she did not intend to. This temporary slowing down / refactoring is IMPORTANT as it makes the system more resilient to the 'new' types of changes being requested and it keeps people chugging along at top speed (or close to it).

Here is the practical take away, systems that do nothing but implement new stuff all the time and pay no attention to the things that pin them up (the pillars or underlying architecture) will eventually become so decrepit as to actually slow coders down when attempting to DO anything with the code. Refactoring is a necessity to keep people using and re-using code. It is the re-using that keeps the speed of implementing new things high and allows development to accelerate and succeed. The best case is to have accelerated (by re-using code) your development to the point at which it is lightning fast and hold it there devoting some percentage of energy to not decelerating from that really fast point.