Coding management

I had a discussion at work today with a project manager. She used to be a programmer back in the days and she shows both insight and interest in code related issues. Not to mention stubborn until proven wrong (no offence, you know who you are and you may see this post as a follow up on the subject). We had several in depth talks about different subjects in programming philosophy but the one that I want to bring back to surface is the one about coding conventions and project rules.

She told me about a successful project where all programmers got together and decided that they were going to follow a pretty simple convention of how to declare functions and subroutines (this was VB 6 I may say). Everything with informative texts that short and concise should inform anyone reading or calling this particular code what it actually does. Also the most important thing was that the writer was indeed responsible of releasing any allocated resources before return.

The reason that we end up in this discussion was the subject of scrum, which encourage programmers to be creative. Let’s face it, all projects have a couple of kick ass coders, some great coders that are eager to learn from the ass kickers and some coders that destroy the project for the others. Creative destroying programmers can be a mess.

This project was no exception. There was this one guy who didn’t care about documenting, and worst of all, he seldom released any allocated resources. This one guy made the whole project limp, and the moral sank, making all the great programmers unhappy and unproductive.
Now why am I telling this story? Could this problem be solved peacefully? I boldly states that the problem should never exist. It’s all up to the system architect and his/her choices of technology. Let’s analyze these two problems.

The matter of unreleased resources is of course a product of stateful programming (also known as imperative programming). If the environment that these programmers were working in was based on the principles of functional programming, the resources would be released automatically when returning from a function or procedure. They could be more careless with their code, and as a result more productive.

Second the matter of documenting the functions and subroutines. We all know from experience, few programming languages require a couple of informative lines of documentation prior to any major declaration. So how do we ensure that they are there? Eiffel successfully turned documentation into a major advantage to the programmers with their Design by Contract (DbC) principle. Also there are of course other positive side effects when using DbC. Eiffel and its killer DbC is a huge subject so I drop that for now. However using DbC, the compiler can force the programmer to follow the documentation rules.

Let’s get back to the story. In the end they had to let the bad programmer go because the rest of the team was more productive without him. Before you chuckle to yourself about how you dismiss bad code and their creators, you should take a good look in the mirror and ask if you really write such great code yourself. I know, only by looking at code that I wrote an hour ago that I sometimes write totally fucked up code. The reasons may vary, you may be new to programming or you may be tired or you may be in a hurry to deliver for a deadline. Or maybe you just have a hard time to grasp the concepts. It takes time for some programmers to understand the value of good code.

There are a lot of reasons why some programmers write bad code. What I am trying to point out is that you can reduce the bad code, using the right language and environment in the right place. It’s sad that the choice of language and environment is seldom a choice made by someone who understands the production cycle and the impact the wrong tools has on it. But then again, that person could probably not choose the programmers for the task either.