“Previously on <TV show name>…”, we discussed how a business can slide into the blame game, where the need for accountability can cause staff to avoid ownership, and where every failing can result in additional processes that produce more cost than benefit.
We’re preaching the virtues of trust, but as many a broken marriage will narrate, trust that is broken is often never recovered. For every grade-A star, there is a problem developer lurking behind his three monitors, about to ruin the party for everyone. How shall we fix a problem like Maria?
We’ll look at several common party poopers, and I’m sure you’ll even find yourself reflected in one of the categories. I certainly do. Each of these citizens starts with a low level of trust, and as you retrain them and increase their trust levels, you can drop the obsolete processes that originally served as safeguards.
The Cheats
“Cheaters never prosper”. Maybe life catches up with them later on, but in the meantime they’ll leave your business to clean up the mess.
Recognise any of these?
- Always implements the easiest solution rather than the most correct solution
- Avoids up-skilling when they can hack it with what they know
- Completely ignores agreed-on standards
- Lies grossly about progress on a task
- Never accepts ownership for a bug or non-delivery, always redirects blame
- Always the last to volunteer for a task or a bug fix
- Occasionally the noisiest in the group, jabbering away as a defence mechanism
Solution:
- Individual code reviews. For a period of time, manually check that every code checked in has an attached review. Do the review, pick out the big issues and do not let them proceed until they fix the issues, immediately.
- Group code reviews. Force them to display their code to the group for comment, and then make them squirm on the issues they obviously avoided.
- Avoid debate. Dishonest operators are often skilled at talking in circles until the protagonist gives up. If there is a clear logical case, present it as matter of fact, but ultimately point to authority structures, making it clear that it’s compliance or the exit door. Their prime issue is not necessarily intelligence but conformism, so don’t let them divert your attention.
The Creeps
These guys don’t know when to stop, they cause scope creep. Apart from being insatiable perfectionists, they are so small-picture-minded that the least relevant feature can become their Great Voyage Across the Seven Seas. They need to be harnessed!
Solution:
- Put a dollar sign on it. Have your creeps explain to you how the feature is going to make money, and specifically how the feature will not only pay back the time they’ll spend, but actually make a profit (all businesses exist to make a profit). We explain this philosophy in our post “Bug? More like feature request”.
- Explain engineering tolerance. On mass production lines, engineering tolerance is the allowed error on products like a bag of flour. Getting the exact weight right requires exponentially increasing engineering costs, and the same principle works in software development. It doesn’t have to be perfect, even if the customer is squealing.
- Prioritisation. Have the creep organise the features in priority order, and then challenge them on their logic. See point 1. Ask them to draw a line above the bugs/features that incredibly enough could go unfixed without actually crippling the final product.
The Petrified
Petrification is the deterioration of a tree into a form that is no longer contributing towards oxygen production. Petrified developers come in two shades of black.
Some are just too scared to admit they don’t know what to do, and unfortunately their fears are often justified, because when they do speak to a senior, they get shot down with a look of disbelief or a you’re-disturbing-me glare.
The others are not so fearful of people as much as they are of the unknown. They know what they know and they’re not ready to embrace new technology or approaches for a number of reasons. Maybe they fear that their lack of knowledge will result in bugs, or that the new tech simply won’t do the job, or that the learning curve will be too steep and leave them unable to meet their targets.
By the time others eventually find out what the petrified have been up to, they’ve either burned their time budget, or gone so far down the wrong route that their work will need to be scrapped or passed onto another developer. Even worse, if it’s too late to unwind, you’ll be stuck with grotesque code that leaves you doing workarounds to get around workarounds.
Solution:
- Talk. Some software companies frown on the idea of talking developers, and it’s true that office environments can deteriorate into cacophonic chat rooms which miss their deadlines. That may be true for intermediates and seniors, who typically have opinions about everything, but juniors CANNOT cope without discussing their issues. You simply have to have someone who is willing to listen to most of their questions, and on a sporadic basis too, because many problems cannot wait for the next appointed question slot in 2 hours’ time.
- Affirm. Juniors always sit uneasy with the doubt: “did I do it right?” It may seem to work, but there’s a nagging fear that it was done the wrong way. It’s so easy to do a code review and pick out all the issues, but it’s also important to be proactive in simply saying: you did that correctly.
- Map their progress. When I’ve taught guitar, most students have a feeling that they haven’t made any progress, so you have to point out what they’ve mastered without realising it. Teach them to celebrate their small victories.
- Predict their struggles. When a junior starts on new technology, make a point of telling them when you expect they will struggle, how long to keep fighting before asking for help, and what to do when they’re stuck. While they should at least fight for a while, until Google no longer helps, they also shouldn’t burn the midnight candle when a senior developer will spot the issue in 20 seconds flat.
The Lone Rangers
These guys are typically good people, capable at what they do and perfectly able to produce working software. But they can still break a software system and cause projects to fail.
You see, one of the keys to maintaining complicated architectures is predictability. A big system can still be manageable if you can reliably guess where to locate a section of code and where there is an established pattern for making changes. The lone ranger just does his own thing, can’t see the point of doing certain steps, and either blatantly causes a failure by making unwarranted assumptions, or causes another developer to get thrown off course.
Even if the lone ranger is justified in reworking a section of code, there is usually never enough time to convert all the code, so you end up with a mixed set of patterns, and the ultimate: spaghetti code, the development world’s noisiest assassin, producer of more WTF’s than a FIFA scandal. At least it creates jobs for shrinks.
Solution:
- Talk. Like the petrified, these guys need to talk more often. They need to be aware that other structures were created for a reason. They need to explain what they’re doing so that others can follow or challenge them.
- Demo. Ask them to walk through their code in a quick demo with other team players. If they’ve made good changes, let their work be reinforced – if they’re being daft, let them fight, which is better than working in the dark. If they’ve done good work, let them have their moment in the sun, because it can help them to be more open to recognising others.
- Remonstrate. Glorify the words “team player” and compliment developers for being team players. Let the lone ranger feel left out, and if they still don’t get it, tell them they’re not being a team player.
- Isolate. Retraining lone rangers to become team players is a slow process – in the interim you need to prevent them from causing as much hurt as good, by giving them quarantined tasks that give them less temptation to rewrite the core engine.
