Recently, a developer was telling me that the system was unreliable, and that bugs were always appearing in production after every feature. On top of that, no observability. The business needed the features as soon as possible, they were cutting corners left and right to get it done. Speed was of the utmost importance. At least they were doing manual testing to get some confidence, but it wasn’t enough and rework was high. The story continued with them saying that finally the business was letting them do automated testing and was on board with carving some time to improve the system—but not too much.

I’ll bet that while the features were being done at the speed of light, the developers were praised for their heroic efforts and dedication to the project, possibly spending extra hours to meet the—imaginary—deadline. Do you know how I know? Been there, done that.

This is my controversial opinion of the week: you don’t need permission from the business to start testing, or to start the many engineering things you think you need approval for to do a good job. Do you require permission to breathe?

I said that I’ve been there and done that. I know how it feels not to have control of the quality of the work, how it feels to constantly compromise to build fast the next feature, and the next one, and the next after that. Not only that, I was one of those that said “it is what it is” as a coping mechanism, and hoped that at some point the business would realise the value of quality and allow us some time to address technical debt.

My realisation is that, the same way you don’t need to wait for the manager to tell you to breathe, you don’t need to ask to do something integral to your job. Some interesting questions for you: what do you think your job is, when do you think you’re doing a good job, what are the outcomes of the job? Depending on your worldview the answer will be different. You might think you’re being paid to build what you’re told. Maybe you believe that your job is to only build, without caring about anything else, and that most of the responsibility and decisions are to be made by the manager or the business, including when to fix or improve stuff.

My worldview about my job is similar to what Dave Farley describes:

An intrinsic part of my job as a software developer is to always learn and adapt sustainably, and, for that, I must manage the complexity of the systems I create to keep that ability. “The business”—I detest this phrase, which suggests we’re divided, we’re not the business—doesn’t have the responsibility to manage the complexity of the system, I do. The product manager nor the designer or the manager have the ultimate responsibility to manage the complexity of the system, they’re not building it, I do, the developers do. It’s here when I stop to clarify: the whole team is responsible for all aspects of the product, we’re not silos within a team—even thought most teams are—, each of us brings unique skills and views, and the team’s responsible for discovery and delivery and should have the same goal. With this clarification out of the way, the developers are going to build the system and are in the best position to manage its complexity.

A software developer, in the words of Dave Farley in the book Modern Software Engineering, to manage complexity needs: modularity, cohesion, separation of concerns, abstraction, loose coupling, testability, deployability, speed, controlling the variables and continuous delivery. Are the designer or the product manager going to take care of those for us?

At the same time, from what I’ve seen, there’s a general lack of knowledge about how to create good software and what it entails and a lack of a sense of what good looks like. Concepts like agile, refactoring, Test-Driven or Behaviour-Driven Development, Domain-Driven Design… are not known, wildly misunderstood or poorly implemented or worse, completely distorted. Even senior devs with tons of years of experience, tech leads or engineering managers don’t seem to know these things or have incorrect interpretations of what they are.

I’m aware that I’m being unfair. Many developers would shout that they would love to do these things or manage complexity, but the business doesn’t let them or doesn’t care, that the constraints and pressures to deliver and cut corners are very real. For the most part, I feel the pain, this situation is not rare in the industry.

Let’s be real, it’s a hard battle, the systems of work of many companies don’t encourage nor appreciate quality, quite the opposite, they incentivise the speed at which outputs are produced—the feature factory—over everything else and have a “top-down” and “power-over” worldview. There’s no supportive environment, little psychological safety. It can be such a hard battle that I don’t blame the people that disengage and just get the money, there’s a family to feed, bills to pay, why bother?, protect yourself, I know I’ve done it. Still, here we are. Another day in this job. It is what it is, but I feel we could try to take responsibility for what we own and stand for it, if not us, who will?

If we could band together as one, we could have leverage. In some situations, I’ve been the person who stood up for or encouraged the team so we could do tests, try a different approach or do continuous improvements, only to be undermined by another developer who thought what I said was off-topic, idealistic, or that they could just do it YOLO style. In other situations, it was the tech lead or engineering manager who shot down the idea, with no other developer to support me, but they did support it in private. Sometimes, it was me who failed to encourage the change and gather allies. Another reason to not band together is fear: fear of breaking the status quo, fear of change and not knowing, fear of being judged and singled out, fear of conflict, fear of losing their jobs… If we were to band together and agree that we're going to start adding tests from now on, refactor as we go or whatever it is we need to do because it’s part of the job, then it’d be difficult for the business to say no. On an individual level, if you want to write tests for your code and nobody else does it, and it’s not a challenge to do so (which can be one of the reasons why nobody does it), then go ahead, you are a professional.

To band together doesn’t imply that we now can force our ways and create our little isolated engineering moat without paying any mind to the needs of the business and customers. That wouldn’t be professional nor conducive to good outcomes or great software. I’m not suggesting either that we ignore trade-offs or that we cannot compromise if the situation demands it, but we have to do so consciously, with intent, aware of the implications. If we create technical debt, we pay it back as soon as possible, instead of putting it in a backlog as massive as the black hole in the centre of the galaxy. When you look at a ticket in that backlog and see that it’s from many years or months ago, and you’ve done nothing, or that you don’t even understand what it means any more, you know you have a problem.

Another controversial opinion: creating tech debt tickets and putting them in backlogs as the default and, most likely, only way of dealing with it is the best path to make sure none of it gets done. X: “There’s a refactor or fix we have to do”, Y: “put it in the tech backlog!”, X:

A previous teammate of mine once told me the story of how he ended up putting his foot down so that the team could finally start to address the painful technical debt they had. The manager was shaken, but caved in. My teammate was willing to be vulnerable, the team banded together, and now they’re in a better position. To counter balance this, I could also tell you the times people failed when taking a stand, and disengaged in order to protect themselves. We have to choose our battles.

Let me finish where I started. A developer was recently telling me that the team didn’t do tests and how rework was high, the priority was to churn out features. Knowing what I know now, having experienced similar situations, I deeply empathise and can understand. Though I cannot stop thinking that, maybe, like an open cage, the prison was in their minds.

Interesting links

• Work Produce People — The Far Reaching Effects of Organisational Design. Great talk by Trond Hjorteland. “The way we organize ourselves at work has far reaching consequences for our society. What happens at work cannot be contained behind the office doors, it influences our entire social field”.

• What Does “Iterate” Mean? In this post, Charles Lambdin points out that the word “iterate” in Agile might mean different things for different people. In fact, he asked a few of the co-authors of the Agile Manifesto, and they had different interpretations.

• The Power of Being New: A Proven Recipe for High Impact by Hazel Weakly.

• Front-of-the-front-end and back-of-the-front-end web development by Brad Frost.