It’s a Phase
Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.
You can’t automate removing duplication, but it does get easier with practice. You can usually tell whether there’s less or more of it after every change. As a result, removing duplication feels like improving some objective metric about the code. Worse, it messes with people’s sense of identity: “I’m the kind of person who writes clean code”. It’s as powerful as any sort of self-deception.
Once we learn how to create abstractions, it is tempting to get high on that ability, and pull abstractions out of thin air whenever we see repetitive code. After a few years of coding, we see repetition everywhere — and abstracting is our new superpower. If someone tells us that abstraction is a virtue, we’ll eat it. And we’ll start judging other people for not worshipping “cleanliness”.
I see now that my “refactoring” was a disaster in two ways:
Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together.
Secondly, nothing is free. My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes. My abstraction would have to become several times more convoluted to afford that, whereas with the original “messy” version such changes stayed easy as cake.
Am I saying that you should write “dirty” code? No. I suggest to think deeply about what you mean when you say “clean” or “dirty”. Do you get a feeling of revolt? Righteousness? Beauty? Elegance? How sure are you that you can name the concrete engineering outcomes corresponding to those qualities? How exactly do they affect the way the code is written and modified?
I sure didn’t think deeply about any of those things. I thought a lot about how the code looked — but not about how it evolved with a team of squishy humans.
Coding is a journey. Think how far you came from your first line of code to where you are now. I reckon it was a joy to see for the first time how extracting a function or refactoring a class can make convoluted code simple. If you find pride in your craft, it is tempting to pursue cleanliness in code. Do it for a while.
But don’t stop there. Don’t be a clean code zealot. Clean code is not a goal. It’s an attempt to make some sense out of the immense complexity of systems we’re dealing with. It’s a defense mechanism when you’re not yet sure how a change would affect the codebase but you need guidance in a sea of unknows.
Let clean code guide you. Then let it go.
Back then, when we were in the engine room, we all knew that one of the by-products of misguided Agile software development was an increase in technical debt. That to deliver working software at speed, we traded off reuse and generated some level of fragmentation. This sort of waste was acceptable as we worked to prioritise responsiveness over efficiency.
We knew that we had to stop and clean up on an ongoing basis. The technical term for this technique is called refactoring
.. As we matured, we started differentiating between efficiency and effectiveness. We realised that our focus on velocity was killing agility, that technical discipline is necessary to enable and maintain responsiveness.
..There are attempts to aggregate initiatives into roadmaps, evolve the strategy based on insights, and enable better innovation accounting, but if you go through the literature available, the focus is on the process, not the customer.
Andrew Ng warns us that as we move from the Internet Era to the Artificial Intelligence Era, we will likely need to shift our approach radically. In the internet Era, we focused on AB testing, on short cycle times, and on pushing decision making to engineers and product managers. Sounds familiar? It should, these are all linchpins of Agile.
.. When it comes to codifying and envisioning what enterprise/business agility looks like, the Agile movement is falling short of expectations. In parallel, the digital agencies and consulting firms that are stepping into this white space, lack the independence to pull it off successfully no matter how many articles are published in the Harvard Business Review.
.. The companies that were once known for exceptional product design innovation, fail to recognise until it is too late that they are losing their most loyal customers because they neglect to design the experience ecosystem thoughtfully. I decided to use a hardware example to represent best the fragmented experiences customers endure when interacting with the Enterprise. Yes, I’m looking at you Apple, the dongle company.
.. The enterprise found itself owning a multitude of disconnected platforms, solutions, and products. Quality, security, and privacy suffered as the years of decentralised velocity at the edges generated a bloated, complicated, disconnected, and unmanageable digital ecosystem.
.. there was a well-intentioned and healthy tension between effectiveness and responsiveness. A tension we should not shy away from because, as Jim Highsmith framed it many years ago, adaptive leaders understand they must ride the paradox between these two forces.
.. This time, code refactoring wouldn’t save us, what we needed, spoiler alert, was customer-centred, organisational refactoring at scale. And refactoring did occur, in the form of backlash against fragmentation, waste and the following flavour of “agility”, “Why do I need to write a story and wait for a programmer to add some content on the website?”. Why indeed!
THE CUSTOMER EXPERIENCE ERA
.. The darlings of the Gartner Quadrants and Forrester Waves announced that we were now in the Age of Customer Experience
.. they witness velocity killing both agility and their work-life balance.
.. The CIO and the Agile and Lean communities shifted their attention from products to platforms. They refactored architectures to become evolutionary. The epicentre of this mammoth effort was still centred around APIs, technology and operations in service of the business strategy. The focus wasn’t on the customer’s experience.
THE CUSTOMER-CENTRED INTELLIGENCE ERA?
.. The commoditisation of technology and the digitisation of the world helped us to get closer to the customer; in some cases, with analytics and programmatic, we managed to get too close without ever considering their experience and trust. We managed to get close to the customer without being customer-oriented.
Frankly, it was not that astonishing when the news broke of the 87 million Facebook users affected by Cambridge analytica’s election meddling. Or was it election advertising? For some of us, it was an expected and inevitable outcome.
.. Perhaps, the current crisis in customer trust will finally propel us into a true experience age — Intelligent, personal, relentlessly relevant, connected, dynamic, and consensual experiences. What Prophet describes as living and breathing brand systems with the ability to learn and evolve at scale. The goal has always been to continuously respond to customer needs, right?
.. In Agile management, there is no such thing as an “internal customer.” The only purpose of work is the ultimate customer or end-user. Under the Law of the Customer, the original producers not only meet the needs the internal customers: they are given a clear line of sight as to what value is being provided for the ultimate customer. Satisfying so-called internal customers is merely feeding the bureaucratic beast. It is a pretend-version of Agile.
Act 15. How Do We Get There?
- Ask the right (human-centred) questions.
- Design Led. Agile Enabled.
- Transformational, Visionary Leadership.When companies get where they’re sort of living by so-called making the numbers, they do a lot of things that are really counter to the long-term interest of the business.
.. Business Agility is the ability to achieve sustained business growth by responding to customer needs. If you are not focused on gaining a deep understanding of your customer and on delivering exceptional experiences, you can’t be responsive, neither can you assure their privacy, security and safety. If you have all that but lack operating model agility you are not a responsive business.
.. Technology must no longer serve the business; the business must no longer serve the business. If we are shifting the focus of the Enterprise from looking inwards to the needs of their customers and hopefully also to the benefit of their ecosystem and society — if we accept that this is the formula for long-lasting Business growth and sustainability — then it’s time to look beyond Agile.