About

Managing a team of software engineers is hard.  Really hard.  Some might go so far as to say that its practically impossible to do it well, but that's only because they're speaking from experience.  As a software engineer, I have witnessed my fair-share of regrettable management-decisions, over the years.  I don't blame them, mind you.  How could I?  They aren't developers.  They aren't technically proficient enough to judge the quality of a programmer's code, or to assess the wisdom behind an engineer's design choices.

It's a problem that has existed since the dawn of computing.  Only a good software engineer can be capable of judging the quality of another engineer's work, but good software engineers typically aren't interested in management.  They enjoy software development too much.  Even if they were interested in being a manager, they likely wouldn't be very good at it.  Management requires a very different set of skills.

Managers of software development teams are in a very unenviable position.  It's like herding a bunch of anti-social and territorial wild-cats.  They have very few tools at their disposal to qualitatively judge the performance of their engineers.  Most of the quantitative metrics are worthless:

• Lines of code written per day?  Meaningless!  
• Lots of overtime hours worked?  Could be a good sign or a bad sign!  
• Spending hours staring at their screen?  Might be a lazy imbecile or a genius!  

Of course there are plenty of meaningful statistics after the fact.  For instance, after a project is done, you can tell how well it was written by how many bugs it has, or by how long it takes to fix those bugs, or by how long it takes to add new features down the road.  But what good is that information after the fact?  If the software was written poorly, the damage has already been done.  So, how do you identify the damage before it's done?

Consider this list of questions to which any good software-engineering manager must have good answers:

• Is an engineer's design for a given project going to stand the test of time?
• In a group of developers, which one is best suited for a particular project?
• How accurate is the time estimate for a given project?  
• Is a project taking too long due to legitimate unknowns, or due to the developer's incompetence?
• Are the bugs due to the nature of the beast or due to some avoidable mistakes?

I figured that with all of this talk in our industry about methodologies, standards, best-practices, and performance metrics, there must be some good, practical resources already out there to help managers navigate these difficult waters.  Apparently I was wrong.  If there is, I can't find them.  

Rather than simply admiring the problem, I've decided to do something about it.  I have no delusions.  I don't expect that my musings will solve the industry's woes.  I do hope, however, that this blog will be one more tool in your belt as you scale this seemingly insurmountable cliff.  As a software engineer, I feel like I can help you.  I don't want your job.  Honestly, it looks terrible.  But I do understand the technical side of things and I think that I can give you some practical advice which may help you answer questions like the ones above.