Let Great Developers be Great

Discouraging innovative developers needlessly hinders productivity

Whether intentionally or unintentionally, you have hired a Great Developer. Congratulations!  They are a rare breed.

One advantage of hiring a Great Developer is that they recommend changes to your technology stack – and they are well-qualified to make such assessments. Perhaps they suggest replacing a closed-source application container with an open-source application container that starts up in 3 seconds as opposed to 3 minutes. Perhaps they suggest replacing an XML-based application container that is hard to refactor with an open-source Java-based application container that is easily modified. Perhaps they suggest using an open-source acceptance testing tool that they have personally created, which will eliminate an enormous amount of cruft in your codebase.

When this situation occurs and people retreat into defensive mindsets, it is important to remember that this is the exact situation for which the Great Developer was hired – to identify and improve upon potential bottlenecks in your development process. Some of the fallacious arguments that can be deployed are as follows:

  1. XYZ is open-source, so we do not own the Intellectual Property Rights (IPR)“. Most software organisations do not own IPR on an enormous portion of their codebase. For example, company C creates application A to sell hire cars. A runs on Jetty, using Spring and Hibernate to talk to an Oracle database. C has no IPR claim on any of the above tools within A, and nor should it care – because they are infrastructure and uninteresting. What C does own is its business logic – the proprietary code developed in-house that weaves together the above with the car hire business requirements. An open-source infrastructure tool that frees up developers to work upon business logic faster is therefore valuable.
  2. XYZ is a security risk“. Quality open-source software components tend to be as secure/insecure as corresponding closed-source alternatives, with the added advantage of Linus’ Law. Consider proportion – is the security of an open-source application within your technology stack the most urgent security risk within your organisation? If so, you have excelled in solving some incredibly complex security issues – or maybe not…
  3. XYZ is a non-standard library“. There is no such thing as a “standard” software library, unless a software vendor is trying to sell you something expensive and unnecessary. Spring is not the “standard” application container. Hibernate is not the “standard” object-relational mapper. No one OS is the “standard” development environment. Bodart’s Law is correct when it states that Uniformity != Efficiency.
  4. XYZ was created by a contractor“. Contractors are paid to come into an organisation, innovate, introduce new ideas, and then leave on short notice. By that yardstick, a contractor that does not attempt to introduce XYZ is not working to maximum potential. There’s a reason why McLaren don’t penalise Lewis Hamilton for continually trying to drive faster through the Monaco tunnel – they are paying him to do exactly that.
  5. XYZ has a Bus Factor of 1“. It’s true that any component in an organisation that has a Bus Factor of 1 should be a concern, but (again) any such assessment should be evidence-based and proportional to the size of the problem. Understand which employees are performing a critical role alone, rank in terms of priority to the business, and start knowledge sharing today.
  6. XYZ is OK for test code, but not for production code“. This pernicious argument is dangerously unprofessional, as it implies that test code is less important than production code. Test code is not less important than production code – it is as important as production code. It demonstrates (to the best of our knowledge) that our production code will work, and what could be more valuable than that?

Great Developers are a rare breed – it is thoughtless at best and ungracious at worst to complain when they are Great.

Tags: ,

1 comment

  1. Sam Barker’s avatar

    The real way to kill innovation within your team is to clamp down on original thinking. Let them use the tools of least friction. If that’s not your standard its telling you something about your standard.

    As Steve said great developers are really hard to find, but if you give good developers freedom to innovative you will find your self with great developers or at worst a bunch of useful tools and code.

Comments are now closed.