Through all the years building and consulting on software and technology, you tend to notice patterns. As enterprise technology has changed over the years, so has the way we build software. Things have gotten noticeably easier as the water level has risen to hide the debris underneath. Containerisation, the cloud and a million JavaScript on the server have meant we can build bigger, better and faster than ever before. But building the technology has only ever been one half of the equation.
In the enterprise software world, we usually have the business and IT functions as the two sides of the enterprise software coin. Each had beef with the other, one because the people with no software engineering skills ultimately made the technology based decisions and the other because they were forced to deal with what they felt as a cost centre as opposed to a profit centre, like the business was, that "just write code and have no idea about the business side of things". In some respects both sides were right but also there was a lot of assumptions in there that made developing software a hugely political affair. As a result the technology faltered and the products did not evolve at a pace that they could do. Bad project management and late in the day business interference meant dropped features, increased technical debt and hellish releases. Arguments surrounding testing and bugs and scope creep and many other blame game situations. It took its toll on both sides and done nothing to bridge the gap in knowledge sharing or respect between the two worlds. Then came Agile.
Agile was meant to solve the perils of the old waterfall methodology. Removing silos and the invisible walls of accountability and responsibility so that cross-functional teams could work together and iteratively progress products, services and the software continuously. It was to be a dream. Maybe I'm biased but I've always felt that Agile was accepted more in the technical side than the business side. Agile gave short development and feedback loops, increased sharing and communication and gave structure and logic to what needed to be completed. But on the other hand, the business ultimately had to relinquish control and this didn't sit well. The business enjoyed the freedom of changing requirements, altering timelines due to political motivations and ultimately they never felt that IT were their peers, just a group of developers leveraged to achieve a goal. Agile was to level the playing field only some never truly believed they were playing the same game.
Throughout my software engineering years there has always been a topic that divided the camps. The rewrite vs refactor vs don't fix it (even if it is broken). Somehow the thoughts of big refactoring efforts were so scary that the organisation would remain on a doomed technology path rather than improve it. Tech teams would shout and explain what was broken and would be faced with excuses citing risk and timelines, even though, once you've seen this play out a number of times, you know that the refactor or rewrite would be implemented quicker overall and would improve an already dire situation and provide value in the future. Surely the development teams were not the only ones that could see this? In some cases, I believe this was true. I believe that in some organisations the business do not actually understand the technology on any level to engage in a conversation or see the value in a rewrite or refactor of broken or ill-designed functionality. They continue to look at engineering requests as a cost over time and choose their own feature pipelines as more important. The hypocritical thing about this then is that the business are usually the ones then that complain about the congested test environments, the late night releases, the forced rollbacks due to issues. All of which are symptoms of the problem that the suggested rewrite or refactor aim to solve. So why did this wheel spin continuously like this for so many enterprise level organisations? Fear of change and fear of loss of control.
Humans are only driven by two things in their lives. Avoiding pain and seeking out pleasure. To make any lasting change requires short to medium term pain in order to bring about the change. The obvious trouble with that then, is that it's very hard to convince a group of people to embark on painful behaviour in the short to near term in order to reach a goal that will improve things from that point onwards. The business groups within enterprise software organisations hate pain. The software engineers also hate pain. The difference between the two groups is that one is willing to change and the other is not. I believe this is the case because software engineers are used to change already, it's part of their career. New technology and frameworks, new languages and constantly improving technology landscapes mean they are constantly updating skill sets, thinking differently on solution architecture and in some cases, having to throw away old assumptions and beliefs about building software and technology (not all can do this and I'll write about that in another post). The business on the other hand, do no not. They are armed with their MBAs and Marketing degrees, their knowledge on psychology and most of all their in-built opinion that software engineers cannot possibly understand their world. The business want a status quo, a consistent and repeatable process that they can run their feature pipelines through with as little interaction as possible required with the software engineering departments. Anything that breaks that cycle, causing pain for the business is shut down. It's that simple.
What then, is the solution to this stand-off? Apart from replacing your ageing and out-of-time business teams that is! Well, we just need to rewire how we perceive the pleasure and pain of our worlds. The business need to look at the perceived pain of not making change and decide that the pleasure of not dealing with it today, is inferior to the pain that will come down the line if nothing is done. To stop choosing the easy road now, in favour of the superior road in the future. If they can believe and decide that the future pain will be worse, then they will embark on a process to endure pain now with the expectation of pleasure in the future. Where do you think phrases like "You cannot make and omelette without first breaking some eggs". Short term pain is required in order to gain something better in the future. It's a universal law. You have to put in in order to get out, it's an energy type thing. And the kicker is, that to create something new requires more energy in than will come out. Balanced energy in and energy out just maintains a balance after all.
This post may seem like a one-sided engineers rant at the business folks in past organisations and yes, I guess it is, as the history speaks for itself. I've heard about places where I've previously consulted having implemented change (finally), but guess what? They only did that when the pain became too great and they were forced to make the change. The same net result as what I explained above, but it took them two years longer and a lot more pain in the long run than if they had taken charge and controlled that change and come out of that process unscathed.
This is why enterprise software takes so long. This is why enterprise software is so expensive. This is why enterprise software has so many politics. Fear of change and the misplaced energy of protecting the status quo and information silos. Things will change, but as before, only when they are ready.
We’re ready when you are. Simple schedule some time below and let's discuss your business.