Back in March my colleague Eamonn and myself presented a talk at GOTO Oslo . The theme of the talk was What We Left Behind: Forgotten Lessons From The 1990s. Item nine was to Feel The Fear. We predicted that, as in the Dot-com Boom, the industry was in a period of explosive growth that could not be sustained. Eventually something had to trip us up. We did not expect to be proved right so quickly.
It should be said that this crash is unlikely to be as bad for our industry as the Dot-com Bust. It is a crisis that the IT industry is well placed to weather, at least when compared to industries like Tourism, Catering and Leisure. But nevertheless the effects will be severe and long lasting.
As we all reflect on where the world goes next it's wise to start from the Greek aphorism of 'know thyself'. In that regard I would like to expand on our talk by listing five delusions that our industry seems uniquely vulnerable to. I claim no immunity, and discovered these first hand by falling hard over each of them. As we say in martial arts "the mat is the best instructor". To leave no doubt about this I've thrown in examples of acts of stupidity from my own career.
Potential Equals Demand
The biggest mistake made in the 1990s was assuming that because something could be done it should be done. Investors fell in love with the idea that everything would be sold over the Internet, neglecting to ask why everything at the time wasn't 'shop by mail'. Eventually innovation outpaced customer demand and the revolution ran off a cliff.
As technologists it's natural to want to move everything to the new shiny platform. At one point in my career I was obsessed with CORBA, and tried to turn every system I was involved with into an N-Tier architecture. Back in the day this was about as smart as proposing that internal mail be run via carrier pigeon. But I persevered and talked some very patient managers to death - thankfully they were smart enough not to believe anything I said.
Ultimately not everything that can be a Web App should be a Web App, not every Web App should be converted to Mobile and not every Mobile App needs a Serverless backend. So when planning for future growth remember that the limiting factor is consumer enthusiasm and not the potential of the technology. Change has to be paid for, and sometimes the client just can't be convinced it's worth it. Frequently they're right.
I Code So I'm Special
Being made redundant is a terrible thing. You get taken into a room with your manager and someone from HR, given the bad news and walked through the financial package. Then there is the horrible show and tell in the canteen afterwards where you find out who is and isn't leaving. In a twisted way it's like graduation day, where you're talking about future plans and promising to keep in touch, except instead of being handed a diploma you've just learned you aren't as special as you thought.
In my experience software developers are some of the friendliest, kindest and thoughtful people you could hope to meet. But we do tend to think of ourselves as an elite profession, immune from the ebbs and flows of the economy. My colleagues and I certainly believed it circa 1999, but events taught us otherwise. Unfortunately the sobriety this instilled into the industry has been eroded by over a decade of calm seas and following winds.
If you entered the profession after 2008 this is not your fault. We all accept the world as it presents itself to us. Hence if all you have known is increasing demand for your profession then its tempting to think this will endure in perpetuity. It won't. So take responsibility for your own career, keep your skill-set up to date, save for a rainy day and develop skills and contacts beyond the software community.
Profit Equals Fitness
Very similar concerns apply to companies. Back when the Dot-com bubble burst I was a fledgling consultant, working with eight others delivering services for a couple of dozen clients around Ireland and Europe. We were somewhat shocked when two thirds of them vanished within a few months. These were highly profitable companies, ranging from small startups pursuing a dream, through medium size firms doing contract development to international telcos like Nortel.
But, to use a nautical metaphor, they were like sailboats rigged for clear skies and calm seas. Many had gone so far as to sell off stolid lines of business with established clients so they could focus their developers time on the internet gold rush. When the crash hit they could not survive the investment drying up, their new clients going bankrupt and the remainder insourcing the work or finding a cheaper alternative.
The lesson for me was that a smart business, like a smart investor, keeps a diverse portfolio. You have to treasure and celebrate established clients (even if the work is boring) whilst pursuing new ones (even if the technologies are scary). The companies (and individuals) that don't survive are the ones that are overly well adapted to the current situation, and don't plan for the winds of change.
Quality Is A Constant
Back in the 1990's I was instrumental in bankrupting a startup. My project was a desktop application where the UI for the POC had been created using a WYSIWYG drag and drop tool. As is often the case, the output from this tool was hideous. So in my first week on the project I worked long hours into the evening, painstakingly writing an equivalent UI in pretty looking Java. At the weekly show and tell I proudly announced what I had done and got a roasting in return. When I went to our CTO for a whinging session I will always remember his question: "I can appreciate what you have done Garth - but why should the client give a damn?".
One of the most common delusions in development is making a sacred cow of quality. But consider an Android app with hideous code quality. Users are up in arms about bugs and it takes forever to add features. If we double the quality then there is a commensurate increase in user happiness and project velocity. Double it again and there are still many benefits. But there is a line past which the game is not worth the candle. If we persist we reach the stage where obsessing over quality is slowing down the team and frustrating the client. For example it's not uncommon to find a team obsessing over a performance issue that either isn't relevant in deployment, or could be mitigated with some smart product design.
Of course there are counter-examples. If you are working on automated trading platforms or aircraft control systems then obsessing over details is part of your remit, because tiny flaws can have huge consequences. But otherwise I recommend you leave perfection to the penniless poets. Professionals do the job they were hired for and get paid.
We're Doing Good
Until very recently the overwhelming majority of developers have felt pride in their work. We believed we were helping build a better world, that that Internet would be a force for good. We thought that the Web would enable education, increase equality and promote democracy. We might have been wrong.
Of course people have always been overly optimistic about the effects of simply making knowledge available. I remember when some of my politics lecturers were first shown using Gopher to download the Constitution of Sweden in only 30 seconds. They predicted that the increased availability of information on systems of government and voting methods would be a powerful force for driving improvement in our own democracy. No one saw the kitten pictures coming.
Today we know that targeted stories on social media can be used to influence millions of people to act against their own interests. None of us are as rational or unbiased as we like to believe, and with enough personal data anyone's opinion is ripe for manipulation. As developers we like to think that we're morally neutral providers of platforms, and what the clients do with them is not our concern. Nothing could be further from the truth.
Conclusions
I hope that these have provided some food for thought. Feel free to add your own below. If you're interested in discussing them in person (albeit virtual) I would encourage you to attend this month's BASH, where the theme of the day is Ethics in Software. We're always on the lookout for new speakers as well, so please get in touch if there is an issue dear to your heart that you would like to present on.
