Byting The Hand That Feeds You

I'm flipping through a magazine that I picked up at work that basically details the latest and greatest components one can buy for doing development in the .NET framework. I'm noticing that there are quite a few ads in this particular magazine (as with all "techie" mags) and a great many of those ads are geared towards products which claim to give managers "control". Now let me first state that anyone who has done software development in a real world environment (i.e. not in a university lab, not at home, and not for your brother in law) knows that the words "control" and "software" have a relationship that is a mirage at best and a complete fabrication at worst. Control is an illusion.

The reason it is an illusion is that for the most part software development is an iterative process. No matter what methodology you use for development (agile, RAD, team, traditional, hokey pokey, whatever) you usually end up with something like the following:

  1. You draft up what you want in some form of structure (unit tests, architectures, prototypes, etc)
  2. You write the code
  3. You test the code
  4. You revise the structure
  5. You rewrite more code
  6. You test more code
  7. If requirements are met, you're done. If not, start at #4 or #5 again depending on what your testing indicates.

The illusion of control lies in the fact that it's very very very hard to predict at #1 how many 4's, 5's & 6's you're going to blow through before the former part of #7 graces your presence.

Now every manager who has ever coded understands this quite well. What most don't understand however is that in order to mitigate the inherent risk involved with committing to timelines, which in a real world business are also impossible to get rid of, it is better to focus on the things within the organization of the team which reduce programmer productivity rather than try to increase programmer productivity.

What I mean is that there is far more time to be made up by focusing on reducing the red tape that may have crept into your development practices over time then there is from trying to squeeze more productivity out of programmers who already have too much to do.

You see, a tendancy in technology companies in general is to think that more is better. More processes = more control. More reporting = more control. Sometimes that is true, but more often those things just lead to MORE confusion, MORE headaches, and most importantly MORE time.

Programmers get paid to write software. Therefore, every single thing that management requires of its programmers which does not directly contribute to the process of actually writing code is inherently making their job harder to do. More rules on what constitutes a valid checkin means less code will get checked in. More TPS reports that must be filled out each day, each week, each month, etc means that actual code takes a backseat to proving that the (lesser amount of) code was actually written.

Secondarily, most managers in IT companies feel the need (either from pressure from above or pressure they create on themselves) to put constraints in place to ensure that the programmers are doing what they are supposed to. This is not only stupid, but completely worthless. First off, if you have hired people you can't trust to do their jobs then no amount of reporting or oversight will make them work. Secondly, the average programmer who is worth his weight in gold actually wakes up in the morning THINKING of the project you have him on currently. He wants to come in to work. Why? Because that's what programmers do. They solve problems. They actually get a thrill out of taking some "problem" that you need fixed and coming up with a great way to do it.

Give a programmer a bad-ass computer, a problem to solve, some cokes and the complete Led Zeppelin box set and leave him the hell alone. If you want timelines, estimates, ROI analysis, code reports, or any other damned thing that is created by management, for management and is indicative OF management…..then have managers do them. You don't pay good money for a doctor to clean out bedpans do you? I sure hope not. (If you do, please email me the name of the hospital you work at and I'll be sure to NEVER vacation anywhere near it).

"But how will I know how long a project will take if my programmers don't fill out micro-detailed reports telling me?" Well, for one if you don't have a good build process set up which tells you DAILY what is being checked in then you're screwed to begin with. But if you do, then get off your ass and check the build report. It should give you a good indication of what areas of the system are being improved. Do these match up with what you've asked those developers to work on?

You can also just ask the programmer. Now if the developer has no clue, he's gonna tell you that. Don't get upset. The reason he is saying he has no clue is because he really has no clue. Try to realize that he is most likely embedded in a maze of steps #4, 5 and 6 isn't exactly sure himself that he'll ever actually find his way out, much less live to tell about it. And the code matters to him more than you do. So the prospect of not being able to fix a problem is far worse than some know-it-all manager telling him he screwed up.

Conversely, if the programmer actually tells you when you can reasonably expect it to be done, then that's what he actually believes. Granted, the programmer may still be in the middle of that horrendous maze, but for whatever reason he has a more hopeful outlook on his chances of finding the exit. I've been programming for years and I'm still absolutely amazed at what arbitrary, stupid things can make something click in my head and give me an idea on a problem that I've been mulling over for hours or even days.

It all boils down to a simple principle really. As a manager you want software. As programmers they want to write software. To get what you want you have to let them do what they want. Controlling the situation is simply not possible in the way traditional models of management indicate you should. That obviously doesn't mean that you should let an employee do absolutely anything he wants………but then again………..


Leave a comment

Filed under Technology

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s