Tuesday, 27 November 2018

DevOps: The Tech Cheeseburger?

How do you feel about change? A great way to gauge a person’s feelings about change is by their reaction to Spencer Johnson’s 1998 book Who Moved My Cheese. This thin volume is subtitled an amazing way to deal with change in your work and in your life and in case you have not come across it you can watch a short cartoon version instead.

The book seems to have been written to help those going through catastrophic and unusual change, probably brought into sharp relief during the massive layoffs and off shoring that were still relatively new in the 1990s. The book was handed out to those who had lost their jobs, jobs they had expected to have for their whole life, and which may even have been jobs that their parents had. I find it hard to believe that being told to behave like mice can have helped much.

Those used to change are more likely to find the book obvious, insulting, funny or all three. I also found the parable insightful into how people who are unused to change, and the few who are just plain change resistant, look at things.

Looking at enterprises we often see that technology groups are split into two organisations, one that is charged with ensuring that everything works, and one which is doing new stuff. The latter is traditionally the software development team but has recently been joined by those migrating to the cloud and introducing IOT. Traditionally the infrastructure side won every battle as they spent more money and hence had more executive clout.

The two sides of this bimodal world are often in conflict, with one side battling to ensure that the cheese stays exactly where it always has been while the other side is trying to find new, more nurishing cheese somewhere else.  How can we make them work together? Well, the answer is obvious: focus not on each group’s cheese, but on the customers’ cheese: yes, move that cheese away from the factions and make them work together.

When creating software this is, of course, DevOps. Bring the people charged with offering reliable, consistent customer outcomes together with those who are driving to make new and exciting things and you should get new and exciting services that are stable. Rather than serving up the patty and the cheese separately, bring the two together. After all, a cheeseburger is unquestionably better than the two items served apart.

Thursday, 8 November 2018

I'm not a robot

We’re technologists, we’re the magicians that make the modern world work. We perform at the intersection of creativity, engineering and craft. Surely our roles are safe from the robots that are coming to claim the jobs? Actually, no, we’re not.  We live in a world where intelligent systems are getting better and better at working with humans. While the ingredient lists for Cognitive Cooking with Chef Watson and the AI-written script for the AI in Progress Bar might be amusing novelties today, they are serious first steps towards a broader approach to augmenting humans.

The way we create software has already changed dramatically over the last couple of decades. Access to endless libraries and repositories on line mean that someone else has already done almost everything you can think of component wise. Vast hoards of open-source software avoid manually digging the foundations without recourse to commercial vendors. We take this for granted today, but it is all very new. Building software has become clicking modules together and wrapping them in layer of specific code to do what was required. No need to continually reinvent wheels.

Three more waves of change are already happening. The first is with smart tools that automate the creation of much of that custom layer. Robotic process automation, RPA, describes a set of tools that watch how people use existing applications and then layer faster, easier interfaces over them. This lets staff be more productive rather than fighting with the usually horrible interfaces enterprises inflict on them. It also removes the need for developing new interfaces to these systems and, perhaps more importantly, it uses actual usage data to optimise delivery rather than what the developers think would work best.  UIPath is a specialist new entrant, while existing process-software vendors are also playing for example Pegasystems Infinity.

The second wave of change is the move towards self-service development, simplifying the process of creating typical apps to the point where those with basic computer skills can build what they need. While this isn’t new – Visual Basic is a classic in this area – however the tools are getting smarter and better at integrating with existing backends. AlphaSoftware’s TransForm is a perfect example. Start by simply typing in a list of the information you want to capture, and it will build you an initial app from that. It’s inspired because that’s the first step anybody is going to make no matter how it is built. TransForm also recognises that fitting in with IT is key, and it allows full extension through a configuration language, while data handles offline storage and backend connections.

Lastly, there is finally a whole new set of specialised programming languages emerging for the bits that do need human construction. Dedicated to a given task, compact rather than verbose, and designed to have mechanical sympathy with cloud architectures, these languages will allow humans to keep up with automation for a while. Some of these languages are new, such as Golang, others, such as Erlang and R, are finding wider adoption after being in use for decades. New languages allow the creation of domain specific languages, for example Kotlin to make programming faster, easier and with fewer bugs.
But watch out even here for automation, as new, automatic frameworks emerge. Google’s AdaNet is machine learning to build better machine learning algorithms – automatically. AutoML – a software robot that builds software robots.

Monday, 5 November 2018

Modern Magic, Modern Magicians

Arthur C Clarke famously said that any sufficiently advanced technology is indistinguishable from magic. It follows that those who master those technologies must be some kind of magician, and unfortunately empirical observation confirms that this is often that case. This can be a problem, because many people like to hide behind that kind of role, keeping those who are not gifted in that way in the dark and dependent.

Before looking at digital technologies such as AI, let’s have a look at motor cars. Used to be that in order to drive a car you needed to have a deep understanding of how the whole mechanism worked. Those who could afford a car could also afford a driver whose job was to keep it in running order as well as taking the owner places. Only enthusiasts, what we would now call early adopters, would tinker with their motors and get their hands dirty.
Nowadays, hardly anybody who drives understands how their machine works. Owners of new cars have little or no knowledge of all the complex engineering that is literally under the hood. Especially no clue about quite how much software there is now involved.  But it doesn’t stop them driving more-or-less successfully, of course, until something goes wrong. The only time they consult a specialist, a magician, who can fix the hex and get the magic flowing again, is when it goes wrong.

Radios followed the same trajectory, from hand-assembled crystal sets to disposable product, and now personal computers too. Only gamers are interested in building their own custom computers, the rest of us are happy to accept pre-configured slabs.
But what about software? The need for consumers to be software magicians has long past, and most consumer-facing software has grown to be much easier to use than it was. Mobile apps have also contributed enormously to software ease of use. Generally speaking this is because, like cars and radios, many millions of people have the same requirements.

Enterprise needs are often unique, or at least somewhat special; a mix of common and specific. This means that magicians have to be involved, but that is changing too. More and more of the ability to cast those software spells is being automated. Just like many other jobs, the robot magicians are replacing humans for routine work. And let’s face it, much of what we do is routine.

So where does that leave the magicians? Working on the gnarly problems that the robots can solve yet for some, and for others looking to see how they can add value and equal the quality of experience offered by consumer software. My next post will expand on that theme.