You have a responsibility. And you’ve been ignoring it.
Almost every month I work with one or two new teams. So I get to see a lot of cool new products, ideas, environments and technology.
Unfortunately, I also get to see a lot of crap. Crappy code. Crappy team morale. Crappy project plans. When this happens, I put on my detective hat and try to get to the bottom of it. In most situations, after asking enough questions, I hear a common reason for the problems: “Our manager asked us to… <x>”.
It seems that managers ask us to write code without pairing or code reviews because that’s a waste of time. They ask us to start developing even if the requirements are unclear. They make us commit to deadlines we know are not feasible.
Why do they do that?
I believe most of the time the managers are trying to do a good job. It’s us, the techies, that are dropping the ball. Let me explain. As I see it, management’s job is to maximize the output of finite resources. So they try to negotiate bold goals hoping that would make everyone bring their A game and consequently the team will achieve its best result.
Unfortunately, in their continuous quest for better results, they often demand things that make sense only in the short term. In order to close a deal based on a certain scope and release date, they ask us to commit to both. To start that new project sooner, they ask us to skip TDD and architecture enhancements for the current project. And the list goes on and on…
And we agree
We have become conditioned to believe that we are not allowed to fight back, when that’s exactly what we should be doing. Our managers don’t always understand the architecture needs, what clean code does for long term code maintainability or how pair programming and TDD can increase the quality of a product.
But we do. And I don’t think we do a good job of explaining the long term consequences of the decisions we are being asked to make. We aren’t brave enough to step forward and have that difficult conversation. We retreat to our desks and lament our manager’s narrow mind to a colleague.
This has to change
As the IT industry moves more and more towards agile, everyone’s voice gets stronger. Every team members is encouraged to express their opinion about potential risks. Naturally, you should have a clear, economically motivated argument for rejecting a request. Not just managers, but every role in our industry should learn to think and reason in terms of (to name a few) customer value, efficiency, effectiveness, productivity or sustainability.
A few examples of arguments you could make:
- Committing to an arbitrary release date could lead to penalties due to delays.
- Eliminating automated testing and refactoring generates the need for a stabilization phase in which no value is being added.
- Banning pair programming means that new team members will become productive in months instead of weeks.
My challenge to you is this: The next time you are being asked something that doesn’t make sense to you, remember that YOU are the professional. Think about the experience accumulated in all the years you’ve been building software. And dare to fight back for what you believe in.