If you’re in charge of a group of developers then you’ve probably had a conversation that starts with,

Hey, um, I was thinking, um, it would be great if I could get a licence for [insert cool software]. What do you reckon?

Let’s face it, developers love playing with the latest tools and frameworks and, while some of the best in the market are actually free, there are some that aren’t, and you’ll be faced with a decision,

Should I say yes?

Well here are my thoughts.

Always ask…

Regardless of whether it’s a $10 or $10,000 license you should always ask the person a few questions.

  • Will this software make its way into production code? – if the software is destined to be used on production code (as opposed to simply a productivity tool) then you need to make sure it fits in with your company’s existing technology stack. You don’t want 10 different components doing the same job – sure this ORM might have some cool features but if it isn’t replacing your existing ORM then it may not be worth it.
  • Have you asked the team whether anyone else needs a license too? – they might be asking for one licence but it’s usually cheaper the more licences you buy so make sure you get a good deal.
  • Don’t we already have something that does that? – make sure there isn’t some other component that does the job that the person making the request doesn’t know about. If you don’t know, make sure they ask the wider team.

Always say yes when…

Assuming your initial questions don’t rule it out, you should just say yes if,

  • There’s no reason to say no – if the only reason you can think of to say no is that you don’t personally like this product then just say yes – it’s not about you. It doesn’t matter whether you like the product, think it will improve productivity or even think it’s a waste of money – by the time you’ve tried to convince someone that they don’t need it you will have wasted more money than the cost of the licence.
  • The cost is less than $x – depending on the depth of your company’s pockets you’ll have to decide what this limit is, but for the sake of a few bucks, it is money well spent if all you’ve done is bought a little joy and happiness to some members of your team. You’ll be a amazed at the mileage you’ll get by letting your team have a few toys to play with.

To be honest, in my experience, developers tend not to ask you to purchase software that’s very expensive – so you’ll probably get to say yes a lot of the time.

 DISCLAIMER – if every member of my team comes to me asking to purchase something small tomorrow I will say no - I don’t have to follow my own advice ;-)

Maybe say yes when…

For more significant purchases, it’s not always so clear cut. Here are some things to consider.

  • It may be better than what you have – even if you have a similar component to that being requested, it’s sometimes worth considering. Say someone comes to you asking to buy a PDF conversion tool. You say, “hey, we already have something that does that in production – why do we need another component?”.  There may be some really good reasons to change – performance improvements, more complete functionality, it may address specific bugs with the existing component… you should weigh up the cost of replacing the existing component. If possible, get a trial version and get someone to spike out a solution to verify it’s going to make a difference.
  • It will make a lot of the team happy – if the purchase impacts more than the person asking for it, then regardless of how important or useful it is, you may still decide that saying yes will improve the wider team’s morale. Happy developers are more productive and stick around for longer – the cost of looking for a new developer who leaves cause they’re sick of using an old version of ReSharper can be a lot more than a few licences.

Say no when…

Hopefully you won’t have to do this too often but there are times when you should say no. Assuming the cost is significant, say no when,

  • It’s pure developer self gratification – “I can’t possibly be asked to develop without X” (spoken with a posh English accent)… it’s expensive, has no value other than a single developer’s personal pleasure.
  • What you have is fine – don’t change for the sake of it, even if there is a newer, flasher, component, it doesn’t mean you have to change/upgrade. Evaluate the benefit and don’t be afraid to say no.

I’d be interested to hear other people’s experiences here – in fact, I think this will be the first topic for the inaugural meeting of the Herders of Coders.