Enterprise IT, be careful where you tread

The client I’m working with at the moment is going through a re-organisation of its delivery teams, and as part of the process they’re also re-evaluating the tooling used for projects. The management has given the group free reign in dictating the frameworks and tools we want to use moving forward, which is liberating, but also potentially fraught with danger. As technologists it’s so easy to jump straight into the “shiny shiny” (thanks Paul), and ignore the reality of working within a risk adverse enterprise IT space. Things to consider:

• Maintainability & Supportability: Software in large organisations is used for a very, very long time. The project I’m working on at the moment is replacing a web application, which is over 14 years old. It’s not necessarily the prettiest thing, but it’s very stable, and more importantly it’s maintainable. People with the skillset are easy to find, and the platform is still supported, which leads to the next point.
• Only proven technologies need apply: I love playing with the latest and greatest at home, but if it hasn’t been proven to work somewhere else, I’m not interested. For example, we’re building a new web-app, and I’d love to write it in Golang, but if I can’t get a Microsoft supported database driver, it’s a hard sell.
• Team Velocity: Pick technologies that your team knows well. If you’ve got a bunch of Ruby developers, build your solution in Ruby. Java developers, a Java solution. This isn’t necessarily exciting, but it ensures you’re getting results sooner.

It’s fun to be able to branch out and learn new tools, but the above should always be considered when selecting new tooling for a project. Is it still going to be fun to work with in a decade’s time?