Disincentives for Doing Things Right
Ask most programmers, and they’ll tell you the proper way to do things. They want Agile project management with two week sprints, they want automated Continuous Integration testing, they want DevOps workflows with rolling releases. They want things done with a quality and a perfection that will make for a flawless system.
The problem is, we never get that system. And even when we do, things get screwed up. We start with the CI system, but as deadlines close, we start skipping the test writing. We stop commenting our code and stop having meetings in a furious desire to hit the deadline.
And there’s our problem.
Software development, like most industries, is in constant flux with regards to delivering products. Better automation, toolsets, and methodologies make it easier than ever to create software, but also leave us with new challenges, most of which many companies ignore, expecting that using Ruby over Java will magically fix all their problems.
Management holds a lot of the blame for this. I know I’ve told developers on at least one occasion that we couldn’t test everything properly: there just wasn’t time in the budget for it, or the client didn’t pay enough for it. And I was wrong to do that, if I truly wanted a high-quality product, something my company at the time advertised that we did, what made us “different.”
The real problem, however, is that there are plenty of things we do that have no bearing on doing actual development, that set developers up for failure and actually encourage them to get things done poorly.
1. Rushed Deadlines
This one drives me up a wall, since I see it at almost every company. Management, for whatever reason, sets a deadline of X days in the future, then tells the dev team it needs to be done in this time. At no point will they talk to the dev team about the deadline to even see if it’s feasible. The best manager I ever had had this as his only flaw: he would ask me if something could be done in two days only after he had promised it would be done to upper management. I made him look bad a few times when I told him it couldn’t be done, there was no physical way to do a brand new mobile app in two days.
This is a real bad practice because it reinforces two principles in your developers: “You are not a part of the discussions about how best to accomplish a project” and “Deadlines are meaningless.” When you’ve broken the engagement with a move like this, you are treating your professional problem solvers (which is what pretty much any engineer is at the core of it) and tell them this is one problem they are not allowed to help solve. You’re demeaning their expertise in their craft. Keep in mind: No one knows better than they how long it will take them to do any task. It’s always best to ask first.
In any case, when a deadline isn’t agreed upon, and you’ve done your own project estimation, you aren’t getting a commitment from the developer on the work. You can’t say, “well, they were slow to finish it” when they never agreed that it could even be done in the timeline set.
A far better practice is to go to the developers, outline the task, project, etc. and get their feedback. You both mutually agree to a timeline, then you hold them to that timeline. That way, you’ve sought out their expertise, made them feel valued, and gotten a commitment from them for that deadline, so if things are going slow, you can use the point that they told you it could be done in that time to hold their feet to the proverbial fires.
2. Team Code Reviews
Ask most developers their least favorite part of their job, and they’ll most likely say code reviews if their company does them. For those not familiar with it, code reviews are team meetings where you get all the developers together, and look at everyone’s code, pointing out points of improvement for everyone. The goal of the code review is to make sure there aren’t any glaring issues (usually easily spotted by developers not familiar with the code but something that will escape the main developer’s eye). The problem is, in most companies, it turns into a blame game. Developers, being people with the full range of human emotions, can deliver biting remarks, calling out bad code and generally making a developer look incompetent to management, even if what they’re doing isn’t wrong, but a different stylistic choice. It often devolves into an argument about the best way to do something trivial like sort numbers.
While it’s a great idea to review a developers code, code review meetings are probably one of the worst ways to do it. Better ways are to have blind code reviews, where developers are not told whose code they are reviewing. This will cause them to give a more honest answer not tainted by how they feel about the developer (positive or negative). Management can then take that feedback to the developer, and present it in a less hostile way. I did my own code reviews for a company whose dev team I managed, and doing it in this way led to higher code quality, fewer defects, and greater developer productivity, because we didn’t need to waste hours having everyone look at the same block of code, when one person was enough.
3. Keeping Dead Weight
There is nothing worse for a talented team than keeping on dead weight. By dead weight I mean developers who don’t produce quality code, are constantly delivering late, or have a horrible attitude. Top performers of any job don’t want to carry the weight of others, and have to pick up the slack. On top of breeding resentment, the increased stress can cause burnout and even cause your best talent to search for opportunities elsewhere.
It also sends the message to the less motivated of your team that you won’t punish poor performance. This can cause your middle-tier workers to start slacking off, thinking they don’t have to work as hard if it doesn’t matter if they hit deadlines, write quality code, etc. In extreme cases your best performers might feel the desire to “give it their all” wane in the face of the current reality that doing well just gives them more work to do.
Which brings us to…
4. Not rewarding good work
As humans, we tend to focus on the negative. It’s what pervades our news, and it’s there because we remember the bad more than the good, as skewed as that might be. So it’s easy to have the squeaky wheel approach to management, where you ignore those who are doing good work in favor of focusing on those employees who are a problem.
The problem is, like training dogs or children, we need positive reinforcement as much if not more than negative reinforcement. A simple “you’re doing a good job” takes no effort at all, doesn’t require you to jump through hoops with the finance department for approval, but can have a huge impact on morale. Everyone wants to be told they’re good at something (possibly because at some point in the day we feel like we aren’t).
If possible, things like raises or bonuses are great ways to reward continuous good work, but there are plenty of other minor things you can do as a reward, such as buying the team lunch on your own dime if they’ve really been getting things done, or even telling them to take a Friday off if you’re ahead of schedule. Again, those kinds of actions don’t require jumping through bureaucratic hoops to get it approved (usually).
5. Taking credit and deflecting blame
The worst managers make sure that everything good is because of them and everything bad is someone else’s fault. Yes, if your company structure is such that you are the only one meeting/talking with the people above you, it’s easy to steal credit. But that doesn’t make it right ethically, or mean that’s the best way to get ahead in your career, as smart managers above you will notice that trend and hold it against you.
As part of this discussion, throwing your developers under the bus when things go wrong, especially if it’s actually something you did, will cause your team to distrust you and definitely encourage them to do less than their best, especially if they know that any success they have will be going on your CV instead of theirs. Vindictive developers may even sabotage the project to try to make you look bad.
Instead, managers should always talk in a positive manner about their team to upper management, and especially attribute success to the people who brought it about. Remember: managers are there primarily to help keep everyone organized and tasked out, and to relay communications and orders from higher up the chain. You aren’t the one writing code, so the fact that a function works without error is due to the developer, not due to you telling the developer to do it.