Managing Programmers

Hi, first post here, been reading articles here for quite a while. So I finally decided I would ask a question and this is a problem a lot of us run into.

Management of programmers seems to be one of the hardest things I have ever done and I know I am not alone in this. I have been a developer, professionally, since 1997 and have worked on my fair share of programming teams. In my past experiences I have noticed that mismanagement is, most of the time, responsibile for most delays, problems, job stress, and just about all negative aspects of the job as a whole. I know there are many forms of mismanagement but here I really want to talk about when a battle takes place between "perfect code" and "shorter timelines".

So I have been part of many projects, and this riddle seems to pop up all the time. Developers, for the most part, take all of the knowledge they have collected throughout their educational career and enter the workplace with an unrealistic set of expectations when it comes to programming for a company. I know because I was the same way. Programmers take great pride in their work and when they are told to ignore a problem to speed up lagging development timelines, the manager tends to run into a lot of resistance.

Sure, we know why developers resist. Even though that bug might be a break in atomicity that the end-user will never see, or its some method that has a single point of failure and you feel that if you don't add some kind of failsafe that the whole world could cause everything to topple and fall... Not to mention you were taught early on that leaving a bug in your code used to lose you letter grades on your projects and you feel that it makes you look bad as a programmer. But now in the real world those project dealines that your professors used to push back for you all the time now cost your employer tons of money when you don't meet them. So as a manager I now find myself fighting company owners to increase deadlines and fighting programmers to focus on completion first, features second.

So I would like to open a discussion from both sides of the fence. I would like to hear from those of you who develop and have found yourselves in this situation and from managers. How have you seen this problem resolved? How do you feel when your boss wants you to write sub-optimal code to solve a problem quickly when you know it could be done better? What do you do when the developers under you overcomplicate things and creep away from the scope of the project?

I'm of the belief that one should not manage work one could not do oneself. To this end I've been pretty fortunate for the past dozen years or so to work for people that fit this criteria. I've seen the other side, too, and it's not pretty. I left a company I was with for nearly ten years over management incompetence.

But when those knowledgeable managers have to stop and tell you that something you are doing will take too long and you should place it on the backburner for a release, and you feel that it should be in the release how do you react?

Well to be fair that doesn't really apply to me very much since I work on internal systems not software for public release. However, this sort of thing is what we hash out in team meetings and making these decisions should be a group effort. It is not my role to delay things for the sake of perfection, this is all part of the prioritization of issues and enhancements that should be agreed upon by all persons involved in the project. In this way it very much does apply to what we do for internal systems as well, and we do have release dates too. Unlike a lot of public release software, however, we bring in key users to participate in some of these triage discussions. Some smart companies do the same with a select group of end users (not just beta testers)

This article is very good about managing programmers, and how they're different from many other office positions.