A Brief Discourse on Morale & Web Development, in Two Parts

Most of the serious thought that goes into producing websites is given to either how to meet deadlines (i.e. project management) or how to actually build the website (architecture and programming).

What little thought is given to soft skills, skills like team building and morale, is very generic MBA management advice. Sadly much of the morale on a project is derived from the style and quality of the code involved, a fact that many managers are unequipped to deal with. Some code bases are so nice to work on that developers find themselves leaping out of bed each morning, vibrating with excitement. Other code bases leave programmers trudging along in despair, unable to engage on any level, taking sick and vacation days as frequently as possible. (Not me, of course.)

Below is a list of things that can make a code base a misery to work on. This list is restricted to code-related issues and doesn't contain more generic problems like shifting specifications and endless meetings.

• Bad Code – If even a small portion of the code is visibly bad and or sloppy it will start to eat away at morale. What's worse, in a classic case of "broken window syndrome" developers seeing bad code will feel like it's ok to write more bad code around it.
• Unpleasant Libraries – Some development libraries are just written poorly. Much like bad code, bad libraries make developers hate life. They also encourage crappy hacks to migrate into the code.
• Out-of-date Comments – Comments are good, but if the comments say one thing, and the code does something else then they are much worse than useless. Great comments are comments that explain why the code is doing what it does, not what the code does.
• Oversized Milestones – If you have to go for too long without hitting a milestone, then morale is going to start to flag. Nothing feels better than the sensation of forward movement.
• Falling Behind – Once the project starts to get behind schedule, people start to feel like it's a disaster, or worse yet, start ramming out crappy code to try to get back up to speed.

As with most problems, the easiest way to deal with these is prevention. It's much easier to avoid using an unpleasant library than it is to switch libraries halfway through the project.
If we all started with green-field projects and never made any mistakes, this could be the end of the article. But unfortunately life is messy—often we are handed brown-field projects that have one or several of these problems.

Stay tuned for my second post on this topic where I’ll outline solutions to the problems listed above.