How hard can it be? The power of optimism and naivety.

Photo credit: Michael Holley via Wikimedia Commons

‘ . . . and now I couldn’t do it because I could see right off there’s no way you could do this. But at that time, we lacked the benefits of age and experience.’ (Ed Roberts, creator of the Altair 8800, the first home computer.)

‘I was so nervous, I felt this is just not going to work - and it worked!’ (Steve Allen, co-founder of Microsoft, on running BASIC on the Altair 8800 for the first time.)

‘We didn’t know what we were doing.’ (Steve Jobs, co-founder of Apple, on creating the Apple I.)

‘How hard can it be?’ What do you think when you hear those words?

If you work in enterprise technology, it is possible that they make your heart sink. You probably usually hear them said by a non-technical sponsor when they have described something that you know to be impossible - or at least impossible with the time and budget that the sponsor is prepared to give you. ‘All you need to do is make this thirty year old back-end ERP system talk to our new mobile front-end in real time, with no down time and no security issues. You’ve got a month. How hard can it be?’

It is part of our jobs to explain why things which appear easy are hard (and, sometimes, why things which appear hard are easy). However, I also think that is part of our jobs, as people who are enthusiastic about embracing the full potential of technology, to realise that we don’t know how hard something is - and to do it anyway.

Sometimes we hear technical members of our teams say, ‘How hard can it be?’ about something which turns out to be very hard indeed - and which delivers astonishing results. Sometimes optimism and naivety are superpowers.

The quotes at the beginning of this article come from the early days of personal computing (and are taken from the book Nerds 2.0.1: A Brief History of the Internet by Stephen Segaller: if you haven’t read it, it’s worth hunting it down or finding the PBS series of the same name).

Ed Roberts had the idea that computers should not be confined to businesses or government departments, and that he could build a kit computer that people would build at home. Even though it had no screen, no keyboard, and was programmed through the laborious method of flipping switches to enter binary digits, it exceeded Roberts’ demand estimate of 800 in a year, selling over 250 a day when it was launched.

Steve Allen and Bill Gates thought that the Roberts’ computer could do with a BASIC interpreter, and built one by hand, without even having a computer to run it on - it’s no wonder that Allen was nervous about whether it would work.

And, before Steve Jobs became known as the proponent of elegant design, he and Steve Wozniak built a computer that was little more than a bare circuit board - and managed to sell it. They all set out to do work without knowing how hard it was - and kept going when it turned out to be much harder than expected.

We might think that these are all stories of pioneering geniuses who were working in the dawn of computing, and that we are not those people and it is not that time. How could we compete with these moments from computing history? It is true that there is something exceptional about these figures and that time: it’s hard to read these stories without wishing that you were there, watching something new being born, in all its crude engineering glory. But, while we may not be Roberts, Allen or Jobs, we all have talented technologists in our teams, and, in the field of computing, it is always the dawn.

Take the example of a team I worked with several years ago in a global bank. They did some of the least glamorous work within the technology organisation: they maintained a core banking system which was decades old and ran on mainframes. It was taken as an axiom that the system was fragile, complex and slow to change - and that it always would be. The team watched as other teams around them embraced DevOps, continuous delivery, and a whole range of automation tools built for newer technologies, and heard their bosses say, ‘This isn’t for you.’

Rather than accepting the status quo, they looked at the systems they maintained, and they looked at the tools available to other teams, and they asked, ‘How hard can it be?’ How hard could it be to adopt DevOps practices, to adapt CD tools so that they integrated with a mainframe code base, to run automated integrations and tests? How hard could it be to persuade the owners of change approval processes, used to a few releases a year, to accept frequent, automated deployments to production on a mainframe?

As it turned out, very hard indeed. The team started with a few promising integrations and automations - just enough to show potential. And then got on with the hard job of shifting culture, changing minds, influencing product roadmaps, contributing to Open Source projects. If they had known at the beginning how hard it would be, they might not have bothered. But the sense that this should be technically possible, that they could figure out the way round all obstacles, that the goal was worth the effort, and, most of all, that this was their system and their work, kept them going. Just like the Altair 8800 and the Apple I, the first iteration of the solution was clunky and inelegant - but it enabled them to show a real pipeline where they checked in the code, watched the lights turn green and deployed to production.

I think that we should greet the question, ‘How hard can it be?’ with interest rather than scepticism. We should listen to the enthusiasm and ambition of the person asking the question - and recognise that sometimes they are asking the question because neither they, nor we, know the answer. I also think that, as well as paying attention to sponsors and stakeholders who ask this question (because they have the money and they control the resources) we should listen to our technical teams (because they know the systems and they have the skills). We should give them the space and time to innovate, not just through corporate innovation schemes, but as a core part of their role as technologists. They will often show us that some things are very hard indeed - and then go on to do them anyway.