Cleverness: A Poison for Modern IT

Usually, being clever is a good thing. I want to take back the meaning. The dictionary defines clever as:

Marked by wit or ingenuity

My experience in consulting has made me want to redefine the word as:

The thought that someone is doing something marked by wit or ingenuity, but is really just hurting everyone.

I've spent equal amounts of time on both sides of the dev and ops fences and both fields are marred with cleverness as a symptom of bad process. The more clever I see someone trying to be, the more dangerous they are, and the more they are actually the symptom of bad process and management.

I've had a co-worker refer to people with the "clever" attitude as "cheaters", which can be apt, but in my experience, people trying to game the system maliciously is much less frequent than people who are gaming the system because it offers them gains from ignorance or lack of oversight, hence me rolling with the term of "clever".

What the heck am I talking about? Let's peek through some examples.

The Cowboy

The cowboy has the attitude of getting something done no matter how bad the actual implimentation is. We're going to skip the part here about the cowboy actually getting their code into master and there being oversight, sanity, and checks and balances and focus on the insanity of this type of team member.

Have you seen 700 line controllers in a Rails app full of case statements, parameter mashing, and implimenting its own caching system through a series of case statements? I have, more than once at that.

The cowboy sees nothing wrong with this, even though there's no way in hell you could ever have actual code coverage on it. When you make a suggestion to the cowboy to DRY it up, the cowboy adds more complexity to the code.


This one. Yeah. Ever seen Sidekiq jobs nested 7 layers deep, each one with its own exception handling and logging system? And those jobs not actually persisting data to the models but passing state between the other jobs? And those other jobs having exception handling for the unhappy paths between them? Again, I've seen it more than once.

One tool for all the jobs person probably sees this as a good thing in a lot of ways. One, we're not using new systems and we're just using things we already know, therefore, no learning curve.

However, when you misuse a tool that badly, the learning curve is really steep because no one understands what the fuck you're trying to do.

The utter defeatist

You've probably heard it: "It's already a broken pile of horse crap, I'm just going to layer another quick hack on top of the one that's already a broken hack because I don't have the time to do it right".

This behavior is demoralizing, wrong, feels bad, and makes you a bad example for everyone around you. It makes them feel like terrible people because more than likely, they're just going to accept your PR for the same reasons you submitted a broken pile of trash.

The PM Who Just Doesn't Get It.

Ahh, one of my favorites. This one is clever because while they're not a programmer, they've seen something like it before. They've already spent a bunch of time with "the business" ironing things out so by the time they get to the implimenters, no matter how completely fucking bonkers their request is, it's now etched in stone on your desk.

Sure, you could point out to this person that the logic in the card you're staring at will let users charge things to other user's accounts without accountability or traceability, but no, it's too late -- you have to do it.

Nevermind the millions you're spending on your dev team, their combined 100 years of experience working with projects bigger and more complicated than yours, this PM just doesn't see you getting how wrong you are.

It wasn't invented here!

Ahh. Once I had to travel somewhere. I didn't know how to get there quickly or efficiently, so I engineered a sphereoid attached to a bar, but buffered by smaller lubricated sphereoids. Then I attached this apparatus to a series of gears of my own design. To these gears were attached a method of self propulsion -- small platforms to which I could place my feet and push. I call it "the bicycle". Now if I could just figure out how to get it to stop.

On IT teams, this makes you a bus factor of one, standing in front of the failtrain, begging for it to go faster. Inventing your own mode of transport may be clever, but it's not helping anyone around you until you can perfect it.

Unless you're the size of Google, solving Google problems, chances are, you have no business rearchitecting the wheel when your business is selling tshirts.

The Common Pattern

Each one of these architypes thinks they're doing something clever. That they're solving mankind's problems in the most efficient way. The thing is, they got there because:

  • They're working in isolation
  • They're working without oversight
  • They're working without checks and balances
  • They fear the perception of failure
  • They're not allowed to not have the answer to a question
  • They don't work well with others
  • Their teams are non-existant or unbalanced
  • They're probably context switching so much they can't keep anything straight

Cleverness is a poison here. The culture is so poisoned when people work like this that insanity is the norm, and this kind of culture becomes generally accepted.

Fixing The Glitch

So how do you stop it?

  • Morning standups. Get what people are doing out in the open. Don't be afraid to tell someone to table an issue when they start going long-winded.
  • Pairing. Yes, even on non-development, no, especially on non-development tasks. Expanding a SAN shelf? No, two of you are.
  • Make failure a non-taboo. Embrace it. Learn from it. At my current company we have a fail flag. It's really well made and pretty -- it's an actual flag. You have to take it yourself and admit failure, but we all learn from it.
  • This is a difficult one for a lot of organizations to grok, but if the project that's been worked on for a month is total shit and brings in more tech debt than problems solved, scrap the whole damned thing. Remember that failure is a non-taboo? Well, setting yourself up for future failures should be a taboo, especially when you can see it from a mile away.
  • Hire culture fit over technical fit. Anyone can learn tech. It's harder to unlearn being an asshole.
  • Run your process in the open. Sprint plannings, estimation parties, retros. Do it all in the open. It's easier for 5 devs to say "um, that's a bad idea for X reasons" than to have them be cornered and explain it to one person. This is a two way street, everyone learns from everyone.
  • Balance your team and have emergency brakes. You probably don't want to pair two juniors on a business critical process. If you absolutely have to, be able to inspect the code and pull the emergency brake if it's a wreck about to happen. Again, let them learn from failure and go back to the drawing board. Everyone will be better for it from the folks coming up with ideas, to the PM's to the other devs. You will have a few of these wrecks early on, but in the end, you're making your machine more efficient.
  • Have no babies. If you do, be willing to throw them out with the bathwater. Be as open to criticism as possible, be forgiving. It will pay itself forward.
  • Be blunt when you need to be blunt. Be forgiving of those who are blunt with you. If they're so incensed by something you're doing, there's probably a damned good reason and once you talk it out, everyone will be on a better path. Let your emotions rip, but don't take things personally.
  • Probably one of the most important self-policing things to do is to remember to ask more questions than you answer. Answer as many questions as possible with another question. Jesus and psychologists are really good at this, and look how well they've done.

So these points will fix everything?


Let me be really clear here, these bulletpoints need to be cultural values, because it's really difficult to make them work when one person is trying to live and breathe them. We are all human beings with faults. The bullet points are reminders to us of how to be honest to each other, but building that culture and respecting it is a really difficult thing that involves everyone's participation.

Personally, I am really, really awful at a lot of the things I've said, but I understand that forgiveness, failure, growth, and tolerance are the values that teams need to work by, and I need other folks around me to have those traits when I'm having a bad day, and I need to offer them to other folks when they're having theirs.

I will help you not be clever if you can do your best to keep me honest when you see that I might be trying to do it myself.