It as an essential part of any staff induction programme that people are educated about the complex nature of software development, as well as the general chaos that is the internet. Non-technical folk really must understand that building software is not the same as building bridges and know why. Lock them all in a room I say, and do not let them out until they have grasped some basic fundamentals. Make them sign something, and promise never to mumble the questions, “Why is software so difficult?”, “Why is this taking so long?” or “Can we reduce quality a little to get it quicker?”.
I am not saying that asking these questions should be punishable by hanging, at least not for a first offence. But if you hear these phrases - swift action is required.
It really doesn’t help that we refer to programming as software engineering in the first place. The flexibility available in software engineering is much greater than any other form of engineering and nearly everything you build in software is something new.
Let’s say you want to build a bridge - an age old comparison.
In the real world of civil engineering, we have been building bridges for centuries and the basic principles are well understood. You invest in meticulous design, perform numerous calculations, plan in absolute detail and then build. You can bet your bottom dollar that there will be zero opportunities to change the design once you start.
However, if you are building software you are probably creating something quite new so it requires research and exploration with failure and rebuilding being a normal part of the process.
If we were building a bridge in software, we might start by creating some pillars, then add the road, string up some cables. Someone decides it would be cool to add a walkway. Good idea! So we bolt on a path and then add some more pillars and swap out the cables for bigger ones.
This keeps going until the stakeholder's are happy.
Our software bridge was scoped but it lacked the up-front exhaustive design that a real bridge requires, probably because the stakeholder's could not decide to the nth degree what they wanted in advance - this being the first time someone has built a bridge. Even if they did design it in advance and in detail, it would still be like building a bridge where dependencies such as your environment, tools and materials were all changing around you.
I suspect the first bridge was rubbish. I bet that it failed.
One more thing. In software, 99.99% uptime is excellent. With bridges, 99.99% uptime is catastrophic.
Anyway, enough with the bridges and back to the gap.
We live in a world where all software is built this way with numerous connections and interdependencies. Business people need to understand that software (and the internet) work this way. Because of this, the internet it is breaking, everywhere, all the time and all developers really get to do is paper-over the cracks to keep things running.
You might wonder why programmers seem a little bit different to everyone else… Perhaps you even think they are their own special brand of crazy. Read this excellent article by Peter Welch and things might become clearer as to why.
Everyone appreciates the transformative value of technology, but most fail to grasp how hard software is to develop and maintain - and how close it is to breaking. It is my view that this single lack of understanding lies at the heart of any gap that opens up between the business and IT. It results in friction, lost momentum and numerous wasted opportunities.
Although you might expect a gap to be prevalent in large corporations, surely start-ups should be able to avoid this trap? You might hope so but I have seen many early-stage businesses also find themselves caught out.
Most business people have not been software developers or studied the way the internet works - to really comprehend the internal workings of this tangled mess we all rely on. If they did, they would simply run screaming.
“This developer is telling me that his job is filled with impossible complexity and the mitigation of constant errors. Do I really believe this or are they just not very good?”
I understand your scepticism. If you have never developed software yourself, it is probably hard to believe. I am not undervaluing what you do, but your own job is probably less chaotic with fewer variables at play. As Peter Welch put’s it, working with software can be like, “digging a tunnel under Mordor with a screwdriver.” There are more lines of code in some software than there are bricks in a skyscraper or rivets in a bridge.
So what happens in a start-up where this simple facts have not been universally understood?
It starts with an inevitable lack of synchronicity as the business shifts direction and the technology fails to move at quite the required pace. Start-ups are more agile than larger businesses but can also pivot much more dramatically. If you don’t have the right team and if they don’t get these basic principles, frustration can build in the business and when that happens, you can easily enter a subtle spiral of decline.
Business people want certainty and dates and apply pressure when things are not on course. Corners get cut, technical debt is accrued and problems are greased into the future. Things get on the back foot. Pretty soon business people are saying things like, “What do you mean you have to refactor your code." and "I can do it quicker myself!”. In the most serious cases, mission-critical spread-sheets are created, a cancerous growth if ever I saw one.
Why do technical people not stand their ground under this pressure?
Because they generally respect the fact that the technology tail should not be wagging the business dog. It take a strong technical lead to not to buckle under business pressure when pushed hard enough.
You can break them entirely if you try hard enough. You recognise the signs because they will stop fighting back, smile and do what you want - knowing that you will learn the hard way.
In large organisations it’s like the Grand Canyon, with business folks on one side shouting at IT on the other who aren’t shouting back because they gave up ages ago. Both sides feel they are a different sub-species that speak a different language. Each side of the canyon has a valid but very different perspective of the world. But on a clear day, both can see the huge pile of lost opportunities lying on the canyon floor between them.
If the world of software is about controlling and diminishing chaos, how do you create a culture of universal understanding, where business people do not press technical people to do bad things that will make the world worse?
How do you counter this from the outset in a start-up? It’s easy… Just make sure that everyone appreciates that whether you make software or mopeds, sell peanuts or loans - the chances are that you are still a technology business. Make sure everyone knows what this means, from the Chairman to the summer intern. Make sure that technical people are valued stakeholders and trusted advisors. It's that simple.
At Rainbird Technologies, every employee, regardless of their role, has to build a software project - even if it is just a small one. They create a real thing that they have to expose to the outside world and maintain. Everyone reads Peter Welch’s article and many more like it, because apart from anything else it will make them laugh about how horrible code can get. Everyone understands that all our developers are core to what we do. We are a technology-led business and we are proud of it. Our business people and our technology people are on the same page, all the time.
How do we do that? We do many things but here is a simple one. Every Friday lunchtime we all go out to a restaurant and have lunch together. We do this for many reasons, but mainly because we must stay aligned and united. It is easier for us because we are a small company, but any business can make a conscious effort to give everyone an absolute appreciation for the complexity of the technical world we all choose to be part of.
