How a Software Engineering Mindset Could Break the Spiral of Failure
Software engineering cultures have created many of the solutions and applications without which our lives as we know it, just wouldn’t be possible, just wouldn’t work. So it’s easy to see that the outcomes and impacts of software engineering can and do change the world.
From Netflix, Google to Facebook to Microsoft and Apple, we are surrounded by the brilliance that software engineering can engender for the world. They give the lie to prevalent software engineering personality tropes too. Software engineers come in all shapes and sizes but speaking as someone who is natively a software engineer and who manages teams of them, the one trait they all share is overriding respect for striving and for solving.
Yet we hear of IT programme after IT change program that fails deplorably, irredeemably.
I am very fortunate at this point in my career to be working in an excellent team of leaders who demonstrate just this mindset, with those leading us having a clear-eyed understanding of what compromises must never be attempted while fostering, even insisting on innovation. But I have at times worked in somewhat different environments and since COVID, the number of ex-colleagues in a vast array of other sectors who are reporting a scale of problems that my prior experiences have made me very able to sympathise with and my musings about them have led me to write this article.
The normal structure of a program is that the engineering team is a team or teams within a larger program management construct that adhere to a discipline with a set of rules and structures within their internal teams while other rules obtain externally.
The Agile movement aims to bridge that divide and does to an extent ameliorate some of the most important issues – specialist to generalist functionality, working at purely unitary levels, poor communication, delivery focus and iteratively built small linked component – but it’s simply not enough as we see in the sheer number of rather large and impactful failing projects.
Software Engineering Mindset is only for Software Engineers – or is it?
One of the reasons, I think, we see problems often is that there is a perception and it is certainly the practice, that an engineering mindset is only borne by software engineers. In fact, it would make sense if all the people involved in delivering a project were aware of and adopted a software engineering mindset especially when critical decisions need to be made. Now, even when we can get project managers and business analysts and other non-engineers on the team to adopt a software engineering mindset, those responsible for governance – sponsors and executives who naturally focus on constraints like budget and time over arguably value and expediency rather than engineering tenets that will deliver an almost guaranteed result, also require a software engineering mindset when it comes to developing solutions.
As Chinenye Ikwuemesi lyrically describes (I want to be the software engineer in that article if I am not, don’t you – even if you’re not even a software engineer!) in her article, software engineers seek to solve problems with precision, elegance and style – it’s got to be fit to solve the problem. There are rules for engineering but problems do not respect rules – their very unpredictability is why the rules and discipline of engineering matter so much. We can harness the wind and bend steel and change the direction of a seemingly unstoppable force given enough motivation and resources to engineer a solution. The one casualty of this might be time. But when it comes to real-life projects you can run the risk of being pennywise with time – gain a few seconds on the project to lose days, months and years in business as usual. Save $0.5m a half here and there only to spend $10m there on gaps the engineering might have plugged.
There is a constant tension between the engineer’s need to take the time required to actually do the work and solve, and the executives need to shave off time and money where they think it’s possible and justifiable. There is an uneasy tension between what engineers may believe is justifiable and what sponsors believe is. In my role, I feel this tension keenly. The manager that I have to be, understands the pressing constraints while the engineer in me is resigned to the fact that certain things and processes will take as long as it takes, even while casting about for new approaches and considering other possibilities and running these equations in parallel in the back of my mind.
Equivalents of Real Engineering Compromises in the Real World
It’s a queer thing. Nobody as far as I know, and I do hope this is the case, asks surgeons to close up patients before the operation is complete to save time or to leave implements in the patient to save having to dispose of them or having to wash and sterilise them.
Nobody asks pilots to do whatever is necessary to reduce the length of a flight if the plane is only capable of doing a certain speed and the rules of time and space will not bend to his ready pilot’s charm, however much money it might save.
Even on the erstwhile Concord flights, the calculations do not change – the plane’s capability might. So what do they do? They do what is safe and what is sustainable. They work around the fact that reaching a destination requires a sometimes undesirably long, arduous and expensive journey, and accept asymmetries. Getting passengers off halfway through the flight to trudge through the Sahara desert to save on fuel is not an answer to any conceivable question. Yet this is analogous to what is sometimes required of engineering teams.
A Software Engineering Mindset and Sustainability
Again, what is sustainable? What is the realistic timeframe to find a solution, build it and implement it? In recent years, bridges built in substandard ways to save money have just…. given up and caved in beneath cars and on top of the unwitting people below leading to lost lives; rail tracks built with substandard materials or practices have buckled and created disasters.
Problem-solving is in its way, precise, as long as you understand the problem. You put this here and that there and pull that down over there and it’s a kite or a plane.
If you take a Jenga mindset when a software engineering mindset is called for, it all falls down.
Yet people seem content to make and accept these compromises in the interest of saving time and money.
The ‘CEO Horizon’ Factor
Look, in some places, a CEO or an executive comes in for a few years – he has to make his mark in about 5 years and is judged on these same efficiencies highlighted above, that give birth to monsters of inefficiency through multipliers in several aspects of the business. But it might never be that CEO’s problem. Another CEO will have to ‘transform’ their way out of it but is likely to fall into the same pitfalls. And the wheel turns, and over and over again, we make unsustainable software, decisions and workplaces.
The Scourge of ‘What might have been’
The true horror lies in the fact that the time and money being saved is a pittance compared to what might have been saved and what might be achieved if the solution is allowed to be fully realised. Somebody has to mind the pennies, sure, and people’s productivity can be improved with goals, leadership and some chivvying but sometimes, we chip away at the wrong things.
Software Engineers tend to have a simple guiding purpose to find the innards of the actual problem – the root cause if you will then worry at it till it reveals the kernel at the heart of the seed that grew that root; then they need to figure out how to grow a better tree. All engineers have the same drive in whatever field you find them, It’s how we are built. Doing this over and over leads to mastery and given autonomy, good engineers will rebuild this world for the better. In the meantime, they can certainly build the solution your organisation needs given these enablers.
What is a Software Engineering Mindset
The software engineering mindset is purely about the willingness and motivation to solve problems, to be interested in all the pieces of the puzzle, how they fit together and the parts you can’t see or understand yet.
It is about awareness, knowledge and interest in a range of tools and technology to survey the full spectrum of available possibilities to plug gaps, and attempts to find applications that can prise open an enigma when nothing else has worked.
It’s about a mind that can roam outside of the confines of the problem to find an application from another context that may be applicable. It speaks to truly caring for the impact of what you create or fail to, and dedication.
It’s about daring, it’s about creation, it’s about solving.
A software engineering mindset refers to knowing how your best solution for a component will work, fit and integrate with the rest and understanding that if at any of these levels it fails, it is suboptimal or ensuring you have some options to address those failures.
A software engineering mindset is obsessed with the overall architecture and takes a global view of problem-solving in the context of the solution. It knows and understands areas directly outside of its own sphere and control, understands the dependencies and risks that arise when you pull a component out of the whole.
A software engineering mindset never loses sight of the problem we are trying to solve as-a-team, and never stops burning to find a real solution. A software engineering mindset is not just for engineers. Finally, a software engineering mindset recognises that we are in the capability business – we deliver power and capability to make the things that were defined as necessary, desirable and high priority, happen. It’s a great example of systems thinking.
This mindset is unlikely to produce a specialist ‘MichaelAngelo’ type of engineer who while they may build a single large product of immense brilliance over a long space of time is unlikely to work on a project team.
Themes of the Software Engineering Mindset
Good cultures if they worship anything, worship excellence in what is created not the creator. The latter creates cults which as we have seen can get toxic very quickly. Good cultures strive for excellence; great cultures get the freedom to attain it and do not hog the credit.
Good cultures know the best engineers and programmers are creative and honest, they value innovation and do not stifle it with bureaucracy; great cultures foster and mobilise the innovatory muscles with great leadership and vision. Leaders with the power to do so should be focused on getting their engineers everything they need to succeed instead of removing pillars of stability or force them to compromise on big important parts of the solution. Actions and risks should be mapped to the specific part and power of the solution that is affected. This means a non-engineer leader can appreciate the impacts of varying a sprint or backlog schedules and the like.
See the Whole Picture
Ultimately, in a delivery team no matter how large or small or how they are structured, all sub-teams have the same goals, and it’s important to reinforce this through communication, a team ethos and building a culture that is based on adopting a software engineering mindset across the board and implementing processes and structures that support and strengthen this at every level. If the focus remains on identifying with great clarity and then keeping the focus on the exact dimensions of the problem, even while everybody is working on separate parts of it, the chances of success are far greater.
Kennedy Ikwuemesi is the Head of Engineering at Pollinate International
He loves coding and architecture and all the different ways of solving problems in joined-up ways. https://www.linkedin.com/in/kennedy-ikwuemesi-0a58561/?originalSubdomain=uk