Wednesday, June 27, 2007

a new appreciation for managers

we've all said countless times how useless our managers are, or how our productivity would increase 10-fold if we didnt have to report back to those pesky overseers. i still think that's all pretty true, but the reason isnt because managers are unnecessary, but rather, managers arent doing their jobs well. i dont really blame them, because its really really hard.

one of the major misconceptions that hackers turned software engineers have is that when they're at work, they're building a product. somehow, people get a notion in their head that when they're at work, they get to do things that are "fun". since everyone expects this, the industry has in turned responded with telling its engineers that they are suppose to be having fun. this is just not true.

the first distinction to draw is that when at making a product, you start with a requirements document that you implement and go from there. if you are just hacking on something yourself or even on an open source project, you can do any number of "cool" things that you want. in a corporate environment, you have a deadline, a feature set, and the quality of your product. managers fail to juggle their resources sufficiently to meet all of those things. an effective manager has to know what he has and make it work for the product. they have to make tough decisions about the number of features to be included, while measuring intangibles like code quality. most importantly, technical managers need to coordinate his team, and that means having people skills. they need to read people, recognize the type of people they have, and make them work effectively together. there is often an inverse proportion between the amount of social skill someone has, and their technical ability. while many of you may be outraged at this point, i maintain that its true.

with all the managers floating around, there are bound to be some pretty crap ones. that's when deadlines slip, people get overworked and assigned to tasks they are not suited for. crucial features may be left out and corners may be cut. in the end, you end up with some piece of shit software that the developer then say, mmm, when i wrote something similar to this myself, it was so much better. well, there are reasons for that. this goes into the whole cathedral and the bazaar shit and software engineering theory that i wont go into and assume you are familiar with.

my point is just that, i recognize now, more than ever that managing a software project is hard. if its not some architecture decision, then its some high-school-like personality dispute. its a wonder how any good software gets shipped.

blog comments powered by Disqus