The Four Hundred

Take a walk around your IT department. What do you see? A lot of activity, right? Programmers banging away at their keyboards, animated discussions at conference room white boards, and heavy coffee intake all remind you just how busy the IT department really is. Sometimes all that activity is enough to make your head spin. You might even take a moment to marvel at the well-oiled machine that is your IT department.

However, if you stop and focus a bit, making sure to move out of the way of the energetic programmer, hot coffee and donut in hand, racing back to his cube, you will notice something very peculiar.

It may be in the form of a project backlog report, or you might overhear a conversation with an angry user, but it's unmistakable. And the harder you look, the more obvious it becomes. Right there, in your seemingly efficient but definitely hectic IT department, is wasted energy, poor decision-making, and limited direction. In short, you have chaos. This revelation begs the question, Are your programmers productive? If you're a programmer, a more personal question may be asked: Am I productive?

The question of programmer productivity goes beyond coding tasks, but let's focus on that right now. If you answered yes to either of the above questions, I wonder how you know that to be the case. How do you measure productivity? Do you simply count the lines of code and determine one programmer's productivity over another's? I've known people who thought this way. In fact, I once knew a programmer who could code faster than you can say "train wreck." The company loved him because he finished huge coding tasks in no time. I was young and impressionable back then (I'm only impressionable now), but I still could never figure out why they loved him so much, when two weeks' worth of his coding turned into months, even years', worth of support issues. And to compound the problem, the company usually asked him, of all people, to address many of these support issues because he was so fast. You can guess what happened next: a train wreck.

If you measure productivity by simply counting the number of lines of code, this guy should be on the top of your free agent wish list. He'll code millions of lines of code for you in the blink on an eye. However, if you include additional criteria in your productivity measurements--like the number of defects or his coding techniques--this programmer's value drops significantly. In fact, it can be argued that he is most valuable as the number of lines he codes approaches zero!

This sounds like an outrageous example, right? Not so. It is quite possible that many programmers would be more productive if they stopped programming. That's because there are so many more things to consider when measuring a programmer's productivity than the number of lines of code and how fast one can produce them. One factor that is vital when measuring productivity is quality. What good is it if your programmer codes a new order-entry system in one day, if that system doesn't take orders properly? This may seem obvious, but based on what I have seen throughout my career, the concept is lost on many. You also have to consider coding techniques and use of the particular language. Programmers might be fast, and their code quality high, but if that code is hard to read, or if they don't use the language in the most efficient way, you will be in for trouble when someone else has to make modifications to that code and the original programmer isn't around to provide the secret map.

Now that you have some criteria with which to measure productivity, you have to determine your department's development philosophy, so that you can decide how to implement each of these productivity factors at your shop.

So how do you come up with a sound and valid formula? Sorry to say, but you can't. Each shop must use the factors I mentioned above and weigh each on importance. Some shops (for instance, the one I worked at as a young lad) might measure productivity based on the fact that they can quote a ridiculous date to a customer and actually meet that date, without any regard to quality.

On the other hand, some shops consider a programmer productive only if his work is of high quality. In that shop's view, you can code until the keyboard starts smoking, but if the code doesn't work or works poorly or inefficiently, you are not productive. I tend to lean toward the latter method. But there are limits to this way of thinking, too.

Programmers are so date-driven. They've got to get this or that done by a certain date. Many don't realize that the date arrived at by management or the user community was done so for reasons primarily external to IT, with only minor consideration about how long it will actually take to design, code, test, and document the new software and who will be available to work on that project. Usually, competition, stockholders, or impatient users and customers determine the date they want the software installed, then IT works from that date. I have also seen IT asked first how long something will take, and the business simply says it needs it sooner.

So you can see that it's not entirely the programmer's fault in coding at record speed to get a project in on time. I lived through this myself. We were implementing a new software package to all our locations, and management wanted to whole thing done by year's end. That meant five weeks between each implementation. Of course, each location submitted its own wish list, in addition to the requests for solutions to the bugs found in the previous implementation. But no one ever measured how long it would take to do all the work. They just made up a date and went for it. As you can imagine, things went badly. We had weekly emergency meetings to discuss why the quality was so poor and what we could do about it. I brought up the fact that we should measure how much work we have to do and how long it might take to get that work through our software development cycle. This was scoffed at. "We don't have time" and "We promised these dates to the locations already" were the responses I heard. It's a shame because, as it turned out, we had more work than the current staff could handle, and we discovered that it took longer than five weeks just to get the software through the development cycle, so shortcuts were being taken in both the design and test phases. We made it, but five years later not only are we dealing with some of the fallout, but we haven't learned from our mistakes. What's the saying? "Those who don't learn from history are apt to repeat it."

Of course, you don't want to go the other way and base productivity completely on quality. Am I productive if I code 100 lines of code a year and that code works perfectly? Probably not. So you need a balance, but your shop must determine that balance. It is not practical to expect to get the best of both. You're probably not going to get perfect quality from the fastest programmer. If you do, keep that person, give him a raise, and then have someone slap you to wake you from your dream.

You also want to take coding techniques and language use into consideration. A programmer might be pretty fast and his stuff might be of high quality, but is he coding with performance in mind and using the database correctly? Is the code structured and organized, or is it all over the place and hard to follow? These factors may count less in your productivity measurements, but they should be included.

So now you have some factors to consider: development speed, quality, coding techniques, and department philosophy. But how do you employ these factors? What numbers should you use? What techniques should you employ to measure productivity, while not causing your programmers to measure how productive they are at finding another job? How many defects per lines of code are acceptable? It may be zero, or more, depending on the application and specific deadlines. How much, if any, should techniques and language use count in your shop? And I have not even covered the software development cycle at your shop. What about the whole process outside of coding? Chances are that it is in some need of improvement, too, and I promise I will touch on that another time.

These questions can only be answered after some research and a further understanding of the philosophy in your shop. But don't think an active IT department necessarily equates to a productive IT department. And remember one of the first lessons from the computer as you ponder all of this: garbage in, garbage out. It's the IT equivalent of the Biblical warning that you only reap what you sow.