Very little is funnier than laughing at annual predictions – especially towards the end of the prediction year and, with the benefit of hindsight, chortle heartily to oneself over what a dunce the author must have been.
So to make some mirth to look back on in the dying embers of 2016, I’ll add my predictions to the avalanche of similar articles.
I have mixed feelings for JavaScript. I started working with JavaScript over 20 years ago … I seem to remember reading about it originally in a HTML 4 book while doing my weekly laundrette wash. At that point the language was fairly basic and no one really expected it to gain any real traction.
Fast forward to today and we struggle to move without JavaScript.
I suspect that most developers of any age will have cursed JavaScript and its misuse for many, many years. JQuery (and some of the rather isocratic JavaScript fashions) made it way too easy for well-meaning novice developers to copy-and-paste samples into their projects and produce some of the biggest UX faux pas.
Yet at the same time, all that use has forced the tools (and industry) to evolve.
Thus my mixed feelings.
I've yet to be convinced that JavaScript’s migration to the server (node.js) is a good thing. While I suspect that the technology could be used well, it seem too easy for web developers to believe they can suddenly start server development purely based on developing JavaScript for the browser. Again leading to poor usage.
The one saving grace for node.js is the compartmentalisation of services being promoted by Domain Driven Design and Microservices. This allows teams to use node.js for their server functionality to get started – then simply swap it out with minimal rework if it fails to keep pace.
That all being said; if there was one technology that I would recommend learning it is JavaScript. For all of my concerns, it is certainly here to stay.
“In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.” Wikipedia
For some Microservices are SOA done right. For some it’s a step too far.
For me it seems to be very much the correct mind-set – but I believe we have a lot more to learn about it.
Too many projects appear to have added “Microservice” label to their architecture to provide legitimacy – in much the same way as a lot of team call their development process agile or scrum, when at best it uses some of the rule or artefacts (daily stand up does not a scrum process make).
In fairness however, the term “Microservice” is poorly defined and open to interpretation. For me the key is to make sure that your services are defined enough that changes can be made easily without disruption.
We have had a dizzying array of technologies hit us in 2015 – and I see no sign of that pace abating.
Some of the current favourites will likely lose their shine to the latest new boy on the block – for example, I can see AngularJS losing its crown to Aurelia. And if you’re in the market for a distributed database (especially for the no-SQL community) then prepare to do a lot of reading and comparisons.
While I love to see new technologies, I do worry that few of the technologies have enough time to evolve properly. As developers, we are too quickly switching to something new and shiny rather than working thoroughly with the tools already at our disposal (this is the same desire as wanting to work on greenfield rather than brownfield projects).
That being said, we should always be prepared to switch technology if our current one isn't working. In an agile world we should be perfectly comfortable with swapping technologies – we just need to ensure that we are doing it for the right reasons.
“A polyglot is a person who learns and uses multiple languages.” Wikipedia
Polyglot as a term has been starting to come through in scrum/ agile teams. It is being used in relation to team members being “T-shaped” or being much more of an all-rounder.
“The concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own.” Wikipedia
The IT industry has been pushing people into finer granularities of specialist over the years. When I started my career I worked in IT. I was then a developer. Now (if I'd continued into technical specialist) I could narrow focus to just UI web development.
This is great for when such specialism was needed. When we had silo'ed specialism teams then this made sense.
Now we have moved to agile teams, we need our teams to be self-sufficient enough to deliver a full software increment. So while each team member may have a specialism, they also need to help out in anyway needed to achieve the team’s goal. Now this could be UI, database, project planning, testing, facilitation, presentations, anything – all with “can-do” attitude to focus on team success.
I've been lucky enough in my career to have the freedom to be a technical all-rounder – but even so, it takes a lot of effort to keep up to date with all the new technologies and options available. I do however think that agile teams need to make a conscious effort to ensure that they are as rounded as possible. Be that through knowledge sharing or actively recruiting ployglots – wait to see it appearing in job adverts soon.
The HMRC seem set to make contracting less and less attractive. And with the rising skills shortages in the permanent market, and escalating packages to reflect, then more and more contractors will return to full-time employment.
In fairness, the HMRC are trying to deal with a problem – just failing to do it properly. Most commentators agree that the flaw is in trying to categorise contractors. Currently we have a choice between employee and self-employed.
Most contractors fall somewhere in the middle. They are working as employees yet are taking the financial risk of being self-employed.
For many years the contracting community hasn't been helping itself by trying to avoid tax through various questionable schemes. It is nothing compared to the high profile tax avoidance hitting the news – but unfortunately, because they are generally similar in setup –they are picked up by the HRMC rules.
As a rough rule of thumb, if the contractors works as an employee rather than delivering a project – then HMRC would expect the contractor to fall under IR35 and pay taxes relevant to if they had been employed.
Personally, I don’t agree with the way HMRC are dealing with the situation. They are way to draconian in their approach – if anything they incentivise the contracting community to look for loopholes. Ultimately I don’t see this resolving itself until a third definition is created which correctly describes a standard contractor.
In the meanwhile, additional rules (such as changes to the travel & sustenance expenses for contractors within IR35 due on April 2016) will make contracting more complicated and less attractive.
Like a new time lord regenerating in the Christmas Dr Who special, I generally look forward to what I hope to be regeneration in the recruitment agency industry. I suspect however that 2016 will be another disappointing year with little changing for the bulk of recruitment agencies.
Ultimately we need to remember that agencies make their money by placing candidates. At its most vulgar form it’s a commodity business.
I spend quite a bit of time in that commodity market – being a commodity (candidate) and a buyer (employer) – so see a lot of poor practice.
Poor in this sense is a subjective term – I find it poor, because I know it can be done better. I've seen some great examples of agencies building genuine relationships (with candidate and employer) – unfortunately these are generally drowned by examples of poorly targeted mail spamming, cold calling by rote, scripted questioning and check listing.
For example, I know from personal experience that if I upload my CV to Monster (or pick your own jobsite) then I will get 10-15 calls within a 2 week period – all of them asking the same questions (most of which have been answered in my CV) and most of them looking to put me forward to the same local big employer.
Is it any wonder that so many good people make an active effort to disappear of the grid – taking themselves off LinkedIn, Twitter and even Facebook to avoid agency spamming.
And why do agencies do it? Because it’s hard to find candidates. These techniques, while not great, do have some level of success.
I would argue that agencies could be better. I don’t however expect much change during 2016 – I see agencies continuing as they have done for the last few years – not helped by more and more 1-2 person agencies springing up overnight.
This is subject I’ll pick up in a subsequent post.
All in all I see 2016 being a good year for IT and development. A lot of options will be coming to the table which will be interesting to see.
We will however still continue to see a skills shortage and under representation of women in IT. These longer term problem need focused plans which I'm seeing very little coordinated effort it. Without some proper plans in place then heading into the 2020's could represent some serious problems for the industry.
And maybe that it’s an accurate pattern for the IT industry – so much excitement and focus on the short term with little investment and planning for the long.