Introduction
I always do some work to define my department's toolset (languages, frameworks, libraries, utilities, packages etc.) giving each tool a green, amber or red status:
- Green - can be used with no restrictions.
- Amber - can be used in defined circumstances - this might apply to tools we were sun setting, niche tools that we are forced to used (by a particular product) or tools that we are forced to use to maintain a legacy app.
- Red - not to be used (included on the list because: they were previously approved or just for the avoidance of doubt)
The idea being if it is defined we can have some control over it - we don't want a situation where anyone can use anything.
I'd also define a simple process around how our toolset can be varied - this might be a quarterly review to which team members (or I) could submit proposals to vary the toolset - if this all sounds a bit officious - see the next section on Risks and also the FAQs section at the bottom of the page.
It makes sense for teams and managers to be aware of what new tools are out there, what benefits they deliver and how popular they are - the best can then be considered for adoption.
It's rare that an established development team will have an opportunity to change something as fundamental as it's 'core' development language but it might happen for example when a major new initiative gives the opportunity especially where that means the team will be hiring.
Risks
As a manager I am relatively change (or at least risk) adverse and there's a number of reasons why a typical development department will want to be cautious around changing key elements of their toolset to frequently.
For example changing (or adding) a core language means we will have not only learn a new skill but also deal with maintaining the old skills (as it's unlikely we will be able to re-write all our old code) and maintaining more skills has a number of downsides:
- It might not be a popular role to work on the 'old' technology.
- More skills required means our goals of fully cross skilled teams are harder to reach.
- Linked to the above, we will be more restricted in resourcing options - to understand this consider if you only needed one skill to deliver developments - that would mean anyone could be put to work on anything - a fantastic situation to be in. Conversely as you increase the skills you need to deliver and maintain your applications your resourcing options become more limited. This might lead to projects being delayed, waiting for niche resource or niche resource working on a number of projects at once (not great).
One comparison might be if you consider the ease of maintaining a fleet of one make and model of car as compared to maintaining a fleet of many different makes and models of car.
So those are the cons - we also have what could be a pro or a con:
- Some people would be unhappy with having to learn the new skill (especially if it doesn't relate well to their old skills) - it's not uncommon for people to resist change. On the other hand, if the change is seen as a positive one some or all the developers may be thrilled with the change. so we need to consider this when considering the change.
Finally we have the pros - the benefits we get from using the new tool - probably a productivity benefit or maybe performance.
Eligibility for Selection
To avoid risk, when we are deciding on a new tool - e.g. a language, a framework, a database, a package (e.g. CMS) I like to define criteria it should meet before being considered - the primary one being popularity.
Here's a page which talks about those rules and why they are valid - Selecting Enablers.
Having these rules also helps if rather than considering a particular tool we are considering a type of tool - as it allows us to quickly cut down the number of possibilities.
Example Case Study
The Seed
So lets say that I am aware that a new initiative is going to be kicking off in three months and that we will need to increase head count.
As part of my role I will have been reading industry reports, monitoring development forums and listening to my developers and am aware that there are alternatives to our current java and C# languages and that the infrastructure around them (IDEs, frameworks etc.) is maturing fast.
The reports on the 'new' (actually not that new) languages detail productivity increases and linked to that ease of learning - just what we want for our new initiative.
Initial Assessment
I've been monitoring tools in general, plugged some names into Indeed (US and UK), double checked with Jobsite (UK) and also looked at stats from GIT and two of the languages the developers are keen on appear to meet our eligibility criteria.
Popularity (Roles advertised by Indeed US Feb 2016)
- Java 87K - increasing
- .Net 81K (C# 44K / ASP 20K) - decreasing
- Python - a healthy 44K - increasing
- C++ 38K - decreasing
- Ruby 20K - decreasing
- PHP 20K - decreasing
- JavaScript (Node.js) 7K (JavaScript 63K) - increasing rapidly
In addition I've looked into the productivity claims and whether those claims made sense and feel assured they do - with Python the language is simpler and less verbose than java; with javascript running within node.js (we'll call it node.js from now on) it is again simpler and developers with JavaScript skills (most of mine) can, obviously, easily pick it up - exciting times!
Both are interpreted languages but performance of languages is less of a concern now than it has been in the past - I'm aware that:
- Database performance is more often a constraint than code performance.
- Both languages have options for compiling.
- If it comes to it, there are a number of ways of fixing code performance issues - horizontal or vertical scaling, coding certain function in, for example, C.
- High volume sites such as YouTube use Python exclusively.
So we have a short list for consideration, I talk through with the developers the reasons for restricting the list to node.js and Python and they are happy with the rationale.
Next Steps
So the next steps would be to actively consider what adoption of node.js or Python would mean to the team with a view to making a simple business case for adoption of one or the other.
- What would we use it for (what are the use cases for it's use) - for new projects would it replace Java / .NET or would it be in addition?
- What would re-skilling look like - is one going to be easier to adopt that the other?
- What would we do with the app estate - would we propose conversion / re-writing or are their opportunities (via up and coming projects) to do this?
- etc.
and effectively this work would either lead to nothing or to a business case for adopting one or the other of the languages.
FAQs
It's quite an odd idea to base a key decision like what language we use on job adverts isn't it? Surely we should be considering all languages on their merits and picking the one that fits our requirements best?
The above isn't saying the decision will be based on popularity, rather it's saying we should discount unpopular tools.
If we take it as a given that we want to use a popular language or at least one that will become popular (for reasons why see Selecting Enablers).
Then that means you're effectively suggesting we should also consider tools with low popularities that, presumably, we are anticipating / hoping will become popular - I don't like gambling when there is a big impact if the gamble doesn't come off.
The impact in this case being a development team trained up on a dying / unpopular language and our new apps written in that dying / unpopular language.
In summary where there is significant risk it's seems to be more sensible to be a fast follower than a early adopter / trail blazer.
An industry commentator recently wrote that "you can sleep through the rise and fall of a javascript framework", an obvious exagerration but a comment that does highlight that some caution is needed.
Why don't you just use Google hits rather job site hits to gauge popularity?
I don't see a lot wrong with using job site hits and the problem with Google hits is they contains hits to historic info - so they work in favour of older languages.
What about Gartner recommendations - aren't they the Professionals?
Sure, I value Gartner and they are another source of info I would consider if I had access.
Shouldn't you leave the choice of language and other technical toolset choices to the developers - aren't you supposed to respect them and empower them?
This is a very valid comment the developers should choose the tool but as a manager I think I have the right to consider the overall pros and cons of adopting a new tool and therefore have ultimate say as to what is adopted when.
I would hope that giving the developers guidance and an understanding of the downsides to the organisation of changing tools too frequently or for example changing to brand new tools would anyway mean we would agree.
A way of avoiding any issues would be to make sure the rules around eligibility where understood and agreed by all.
Are you proposing this approach for adoption of any tool - surely the developers should be allowed some flexibility to use what works for them as individuals e.g. their favourite editor?
For tools that impact code or even the build process and require skills to be gained and maintained then their adoption does need to go through a process.
Commonality of tools means people are working in the same way and can easily assist each other and quickly induct new members to the team which is all important.