​Why CIOs and developers are seldom on the same page - and why that's a good thing

They may want different things but ultimately the dynamic between CIOs and developers can be highly beneficial for the businesses that employ them.
Written by Toby Wolpe, Contributor
Itamar Haber: Developers are highly curious, very creative people.
Image: Redis Labs

When it comes to the technology firms choose, most people recognise just how influential developers are. But their role in driving software adoption - and even sometimes shaping an IT strategy - can occasionally put them at odds with the CIO and management team.

The businesses that harness that tension, or formalise it in some way, are the ones most likely to come up with successful technical innovations, according to Redis Labs developers advocate Itamar Haber.

"Most developers are highly curious people, very creative, and they like playing with new shiny gadgets - both to see what they can learn as well as to punch holes in them and see where it breaks," he said.

"The developers are looking for ways to solve their problems or, if not solve problems and the challenges they need to address, then at least make their life easier. That isn't necessarily something that the CIO looks for."

A CIO is probably weighing up the larger picture, along with factors such as security, costs, and maintainability.

"Recently, you've been seeing a lot of frameworks popping up that developers really take a liking to because they streamline their processes or at least allow them to pursue a lot of work they used to do manually," Haber said.

"But the thing is with these frameworks, you don't know what's going to happen in a year from now, whether that framework is going to be there, whether it's going to be maintained and available to do the same stuff they're doing today as efficiently."

So the developers' possibly short-term preoccupations can conflict with the decision maker's long-term thinking, and there are always concerns that the creator of an application today may not even be an employee next year.

"[They're concerned about] finding a replacement for that developer for a technology that no longer exists, because the rate of birth and death of new technologies is increasing and increasing exponentially," Haber said.

"Even if today you're opting for the most popular programming language, or framework, or library, or concept, tomorrow it may be forgotten, and as a CIO you're stuck with that legacy. There's definitely a conflict of interests here."

Haber's role at Redis Labs, which provides hosted cloud versions of NoSQL open-source databases Redis and Memcached, is to raise the company's profile among developers "and anyone else who will listen".

According to Haber, developers tend to want to stay at the bleeding edge of technology, taking immediate advantage of everything new as it becomes available.

"It's just a click away, a download away from GitHub, and we can build amazing stuff - stuff that used to take weeks to build we can do in days, and stuff we used to do in days we can do in hours and so forth. But from a business perspective this could be a challenge," he said.

Software maintainability is only one of the issues. Licensing can, for example, also come into play.

"As a developer, I usually don't think about it. If I see something out there, I just take it and start using it. No one I know bothers reading the fine print in the licence. But this probably creates some legal risks for an organisation that lets developers work like that," he said.

Software that starts out free can become paid-for with, for example, a change in the ownership of the technology.

"Sometimes there are projects where a commercial company tries to or succeeds in taking ownership, and you find that as a user you need perhaps to start paying for the premium version or support," Haber said.

"That could be a challenge for an organisation. Especially if you didn't know about it beforehand and plan for it."

Because those are just a few of the areas where problems can arise from the way developers work, the CIO does need some governance in place.

"But on the other hand, going back to the fact that developers are creative people and problem-solvers, you don't want to limit their creativity and inspiration by forcing their hand to work with only corporate-mandated tools of the trade. That would probably be the worst thing you can do," Haber said.

"Because, if a developer becomes convinced that there's a better solution out there - better being either easier to use or more performance or something that does whatever he or she needs to do more effectively - you do want to let them do that."

Consequently, many organisations that navigate these issues successfully allow for some back and forth, some sort of a sink process between developers and management to make sure everyone is aligned.

The goal should be for developers to know what managers expect of them in terms of how they should choose software and how they should look for potential risks.

"Developers [need to be] feeding their inputs back to decision-makers and telling them, 'Look, this is where we're going, this where the market's going, and you should prepare for that, otherwise you're just going to be left behind'. These days the ability to innovate is extremely important for businesses just to survive, let alone compete," Haber said.

A two-pronged approach can function well for everybody, where part of the development body uses company-issued tools to work on developing and maintaining the lion's share of the business. The other part of the development team is charged with innovation and experimenting with new technologies.

"This could either be done formally or by dedicating 10 percent of the workforce for that or in some companies, most notably Google, by allocating a proportion of their employees' time to do whatever they want or innovative stuff," he said.

The company needs a model where developers can test new principles and ideas, which, if successful and sufficiently mature, can then be adopted officially. The process needs to be relatively low risk and involve only a small portion of IT investment.

"If it doesn't work, you can throw it away. But if there are gains that you can reap out of that effort, you can adopt it very quickly and bring it into the fold. Every organisation is different in the exact ratio it chooses to get involved with innovation, as opposed to doing legacy development," he said.

"Sometimes this is born out of necessity. The organisation comes to a realisation that it got stuck, left behind, and that progress has left it in the dust. Then there's a decision to build this next-gen team that's going to be in charge of the vision and how to implement new technologies."

The database market is a good example of developer-driven innovation, according to Haber.

"After many years when this market practically stagnated and stuck in its rut of relational databases, over the past few years we've seen a lot of changes here - with the advent of big data, and NoSQL and NewSQL and all these buzzwords," he said.

"In terms of data storage, developers were forced to work with a very narrow type of technology - the relational database. We've all grown very accustomed to it - we've all grown numbly comfortable with it."

The relational database has been a great leveller, creating a common language for database development.

"There were no surprises but it also was detrimental in the sense that you couldn't do the amazing stuff that people do today. You couldn't build Twitter or Facebook with only relational databases. The dam broke eventually," he said.

"The world exploded with a plethora of new technologies that are actually not that new. Some of them have been around even before databases but people have rediscovered them. That's a pretty amazing time to live in and developers have been the proponents of this revolution.

"But there are no magic bullets. Whenever one technology is heralded as the white angel, the saviour, as the one technology to rule them all, the unifying technology, it's probably not it."

More on databases

Editorial standards