Hero developers. That breed of super heroes that solve every damn coding problem that arises in our software projects. They are fast, and usually they complement it with lateral thinking, boosting their quickness with solutions that seems taken out of a magic hat. And it seems they are always there when we need them. They have a great commitment to the project, they love to save the day, even on weekends! They seem to have an affinity with programming languages, they even understand the ones they have never seen before… and quickly.
New requirements enter the show with no adjustment in schedule? – No problem, we have Super Javaman with us!
Bugs, bugs and more bugs!!! What are you doing people? PHPman, here… take the key of the office. Stay this weekend, please. We need to be ready to deploy on Monday! Refactor anything you want, I don’t care, but make it work! Oh… yes, and turn off the lights when you finish. Thanks!
Client: “What? I didn’t mean only A and B… What I meant was that we need the app to do A, B, C, D, E, and all the remaining letters of the alphabet!” – Team Leader: Uuuups… better start lightning the C#Signal, we are gonna need Supersharpy right now!
This guys are really great. It’s always nice to have one of them in the team.
But guess what?… If you need heros more than once in a while… you suck as project leader!
Yes, and I’m sorry to tell you this, but it’s true. Don’t take it personally. I have fall into the hero trap myself more than once, so I’m also talking about my own problems here. When a software project has problems, they are usually caused by a bad leadership, and not because of bad developers.
Of course, this is not the way that project leaders want to put it.
“Hey, project leaders don’t code, so why are they responsible of bugs?.”
“Project leaders are not the client, they are not to blame for those unintelligible requirements. The client is!”
“Wait a minute… as a project leader I usually double check all time estimates with a developer, so I’m not the one to blame about bad schedules.”
Really? Is that easy? Are developers so awfully bad coders that they introduce bugs in every code they touch? And if it’s so… you didn’t notice until well advanced in the project schedule?
Aren’t project leaders the responsible of the project, including understanding what the client wants? And if this is not clear enough, don’t they have the responsibility of at least communicate this to the client and try to solve the issue?
Do project leaders come from a parallel universe where time works different than here? Why they can’t understand that time estimates are only that… estimates, not promises? It seems to me that not matter if the project leader was a developer just until yesterday… today is project leader, and now he forgot that a good time estimate requires time. You need to know exactly what you have to do in order to tell accurately how much time is going to take. More time, better estimates; less time, worse estimates.
And all this gets worse at corporate levels. Usually at big companies every one functions in Pontius Pilatus mode, trying to avoid responsibility of any decision. They only lack the water bowl… but if they could have one, the picture would be complete! (I guess that I’m going to code a mobile app of a water bowl, so every time this guys have to take a decision, they can tap the bowl and a voice in latin says something like “The decision is yours… not mine….”).
So please… we really don’t need another hero. We need common, normal, ordinary developers who work good enough to get the job done. But what we really need is good project leaders. The ones that know that software development is a team effort, and know how to facilitate the workflow between team members. The ones that helps them solve problems, and that take the rocks out of the road, not the other way around!
Is your responsibility as project leader to make your team fit together, and to help them not to loose focus in unimportant tasks. Bugs are your responsibility… just ask developers why they have them, and if there is something you can do to help. Requirements are your responsibility… so be sure that everyone understands exactly what has to be done. Schedule is your responsibility… so take the action needed to make the client understand what an estimate means, and don’t fall into the “Holy Bible Syndrome”. And last but not least… please, hear what developers warn you about, they usually make their warnings when there is enough time to do something. If they talk… listen.
So here ends the software development catharsis… After all this, I’m just hoping that I have some readers old enough to remember this: