Genius-proof

You don’t hire fools*, so don’t waste your time fool-proofing your software development tools and processes. It’s actually more important that you genius-proof them.

Our industry is full of smart people, but I’d say significantly more than half of those I’ve worked with over the past couple of decades couldn’t ever take a direct route to solving common software development problems such as creating a straightforward build process, or setting up a simple configuration management environment.

PotatoDanger! Danger! Heath Robinson!

Software development tools and processes are supposed to help us solve problems.

And the best solution to any problem is the simplest one….right?

Well, apparently not. If you look around you, you’d think today’s toolsmiths had been taking lessons from W. Heath Robinson, an English illustrator who created wilfully-elaborate designs for machines that performed the simplest of tasks. His name has become synonymous with unnecessary, pointless complexity.

There should be no place for Heath Robinson Machines in software development, yet we’re surrounded by them. When we create such machines (and by ‘machines’ I’m talking about the tools and processes that are supposed to help us create great software) we’re not creating a sustainable solution – we’re building a bodge that will end up causing far greater problems for us in the future.

This is why we can’t have nice things

Weird, circuitous tool and process implementations are commonplace. The toolsmiths (with a special mention for theĀ FOSS guys who seem to be over-represented) are obviously clever people, but it strikes me that many of them seem to want to build tools in their own image – i.e. clever ones. They want clever people like them to use their clever tools in a clever way to solve even the most mundane of problems. Usability and practicality clearly isn’t something high on these people’s agendas, although over-thinking a solution clearly is.

This Heath Robinson approach often results in opaque, unusable-by-anyone-but-a-superhuman tools that cloud their true problem-solving purpose with pointless bells and whistles, oblique implementations of the simplest concepts and far too many fiddly, inconsistent features that do little else but prevent the user from understanding how to use the tool.

Combine this with execrable documentation and the all-too-common attitude of “If you can’t work out how to use it, you’re stupid” (yes, I’m looking at you again, FOSS community) and you get the perfect storm of your teams building tools and processes that are founded on unnecessary complexity, incomplete knowledge of how things really work, and an unwillingness to endanger their geek-cred by asking for help.

Complexity = Risk

Complexity, whether needless or otherwise (although I never saw complexity that was necessary,) is a risk to your business. Introducing it into your critical tools and processes plants the seed of inefficiency, confusion and eventual failure.

The scary thing about complexity is that it’s self-perpetuating, resulting in…more complexity! While you might start off seemingly OK with a needlessly-complex process or tool, as your project evolves you’ll notice things slowing down. Your team finds it needs to be more and more careful about how it does things like code merges, releases and builds (which are probably the most commonly Heath Robinson-ed functions I have seen in organisations.) Things just take more and more time to get right and more mistakes creep in, meaning more time is needed to fix them up. Mistakes compound on previous mistakes, building increasing danger into your code base. Eventually this becomes unsustainable, and you can’t build your software. Your team can no longer function. Your project is screwed.

So you really, really need to avoid this from happening.

It’s possible to de-complexify (is that a word? I like it!) your needlessly-complex environment but it takes a lot of effort. The best way to do this is to get it right when you set your teams, environments and processes up in the first place.

Avoiding complexity

Here’s a few things to consider if you’d like to avoid painting your teams into a corner due to needless complexity.

  1. Don’t let complexity be something to be proud of. It really isn’t.
  2. Celebrate simplicity for what it is – elegance!
  3. Challenge your teams to minimise the number of ways they solve problems. Constraints breed creativity, and most (if not all) problems can be solved simply.
  4. If there’s one best way to do something (and most of the time there is,) stick to it. The middle of a project isn’t the time for experimentation.
  5. Especially in the case of setting up code management environments, tools and processes, don’t believe that just because your developers know how to write code they know how to manage it. That’s like expecting your bricklayer to know how to design your house. Proper code management is very, very hard to do well. Seek professional help.
  6. Avoid tools with too many bells and whistles (especially FOSS ones, which are pretty notorious for poor usability and limitless ‘flexibility’,) as these just serve to distract people. Hide unnecessary features if you can.
  7. Don’t let the technology guys come up with the process on their own. Let a process person such as a Business Analyst lead its creation. They should be able to spot inelegance and complexity a mile off, and stamp on it before it has the chance to poison your teams.
  8. Inconsistency in a process or tool is a sure sign that there’s something odd going on. Explore it and try to ferret out why it’s not consistent, and think about how that could be a risk for you.
  9. If your team can’t easily document the process in a one-page flowchart and demonstrate it to you, it’s probably too complex.

*If you do, please get someone else to handle the HR.