Tags: | Categories: Articles Posted by RTomlinson on 2/9/2014 3:24 AM | Comments (0)

Dan Pink Motivation Image

I’m seeing this more and more from interview candidates, as well as my own experience. Of course you could argue that the whole reason for being at an interview is because a candidate is unhappy in their current position. Yet what’s clear is that developers, including myself, thrive on using and developing tools and technologies and most importantly removing things (processes/tools/technologies) that just get in the way of productivity. For me, that is the mark of a good developer!

There are some recurring themes that run through the applied reasoning for mandating certain tools and processes and the majority of them are completely unfounded or illogical. There are, absolutely, some necessary reasons for mandating processes; take SOX (Sarbanes-Oxley Act) for example. Often though, when you dig into these compliancies they’re often misinterpreted or intentionally strictly applied out of fear or lack of knowledge.

In an attempt to sway the post from a rant, which I’ve clearly already started doing. I want to address some common excuses:

The “single unified way” excuse

This is often related to using the same tool between teams of employing a technology that becomes the standard. When you do the latter you are saying that the technology that was decided, at that time by a certain person/people, is always the tool of choice regardless of the situation and you take the context out of decision making. Particularly in our industry this is detrimental to the organisation. It discourages innovation and limits the ability of your development team to look outside of their technical skill set. Forcing separate teams to use the same tools means that a team can’t play to its strengths and hinders self-direction.

The “we don’t do that here” excuse

This is synonymous with “we write our own” or “nobody knows it so we don’t do it” excuses. Embarrassingly I’ve actually used these myself and it’s not until I’ve ventured out of my own bubble that I realise how damaging it can be. Making particularly poor choices over tools or processes that get in the way of developers happens a lot and there are situations where the choice at the time was the right one. When those choice end up getting in the way and people aren’t heard then resentment grows.

The “{insert position here} wouldn’t allow that” excuse

I’ve seen this more in relation to tooling and it’s completely illogical. It’s particularly illogical when applied to using SAAS/cloud tools (bug trackers, github, etc). When you force tooling internally you add significant overhead and pain. Some businesses can deal with this and in those cases then it’s applicable but that is the 5% minority. Reinventing the wheel and giving yourself more to maintain takes your focus away from the core of what you do. The US Army, Navy, Air Force and Department of Justice are using cloud services, you have no excuse.

In an industry of constant change it’s important to enable your team as well as provide guidance. This doesn’t mean giving everyone free reign but it does mean giving them the opportunity to investigate new technologies, to innovate and bring that back into the business. After all, that’s how technology companies ultimately survive. If you don’t, you risk losing your developers to companies that do.

blog comments powered by Disqus