I should say before we start that I’m aware that, rather sadly, “Clean Coder” Bob Martin has become rather a problematic figure in our industry. It also pains me to write about the importance of well-tested and maintainable code in 2022 but some of the responses to this Tweet from him reminded me that this still remains an issue.
As a developer this still rings true to me. So why do developers still have to deal with this kind of talk? Did we do something wrong in the past? Are we still doing it wrong? What gives our "bosses" the impression that they can negotiate how we should do our jobs?
I'd like to discuss the scenario Uncle Bob described from several angles.
Are we under the constant threat of being fired?
Whilst we are seeing mass layoffs in the industry at the moment, and obviously that’s a horrible thing to be on the receiving end of, studies and surveys show that the majority of job changes are at the initiative of developers, not the other way around. Moreover, the unemployment rate remains lower in IT than in other industries. According to the Stack Overflow survey of 2022, the percentage of unemployment among professional developers is only 2.28%], far below the 5.3% unemployment rate for all industries in the OECD region.
My own anecdotal experience from more than 20 years of development and software architecture supports this: For every developer fired, there are more than a hundred developers who have left the company at their own request. Nor have I ever seen a case where a developer was fired for wanting to do the right thing.
The industry also continues to expand and needs more professionals in the field. According to a report by the U.S. Department of Labor, the expected growth in software developers, quality assurance analysts and testers between 2021 and 2031 is 25%, well above the 5% average.
Of course, there are events like economic recessions, pandemics, or a rich man buying a technology company and laying off all the employees on a whim. But again, development is one of the most versatile professions and can survive this kind of disruption. Even with an event as impactful as the COVID pandemic, which severely affected professionals in most industries, development proved to be as effective as the orthodox method of office work when done remotely. This virtually eliminated geographical barriers and allowed developers to work for companies from other cities or even countries. In addition, the pandemic added to the demand for software experts as the demand for online services grew rapidly; Google, Microsoft and some of the other tech giants did overhire in response to this, and we’re seeing the results of this now, but it doesn’t change the core point that software skills are in demand.
So it is not the fear of being fired that opens Pandora's box to negotiate quality, but something deeper.
No Professional Ethics Among Us?
Two separate replies to the original tweet mention scenarios where some other colleagues undermine the effort of doing the things right.
These replies are spot-on. I’m sure we all have seen the greedy consultant or so-called hero of the company—the latter often a brilliant jerk still styling themselves as a “10x developer.” These are the toxic characters the industry has wanted to get rid of for so long, but unfortunately, they are still around. If developers want to be respected as engineers (I’m not talking about university degrees here, but complying with the merits of engineering), then they have to behave as such.
As a side note an interesting thing about toxic jerks is that they are so disruptive on a team that removing them allows the team as a whole to move faster, because modern software development is almost entirely an exercise in collaboration. It’s also often the case that when their work is looked at after they’ve gone it turns out to be really very poor—badly structured, hard to interpret, and difficult to maintain. There is no good argument for hanging on to these people.
Negative is sometimes positive
There are two approaches in science. The positive approach attempts to prove a hypothesis through experimentation, whilst the negative approach attempts to falsify it. Both approaches are valuable, and sometimes it is simply impossible (at least for the time being ) to prove a hypothesis using the positive approach, and we are left with the negative approach. The negative approach alone is not sufficient to prove a hypothesis, but if we fail to disprove the hypothesis whilst the possibilities we cover increase, the probability that the hypothesis is true increases significantly.
Software is an area of engineering where there is no way to apply a positive approach to prove that our code runs as expected. We can only try to prove that it is correct by ruling out all cases and failing to disprove the promises of our code. This makes testing an essential part of development itself, not an optional aspect on top of it. No self-respecting developer should negotiate neglecting the necessary tests or the overall quality of the code. Also any developer facing the greedy consultant or so-called hero of the company should make it clear to the boss that the delivery will be lacking these essential parts.
Would you bet your life on it?
Engineers are everywhere, in every aspect of our lives. Engineers build the houses we live in, the cars we drive, the planes we fly in, they produce the food we buy at the market. As consumers of the products that other engineers have built or manufactured for us, would we accept a product that is likely to fail and has not been thoroughly tested? Even if you are in a big hurry, would you consider it if the pilot made an announcement over PA asking, "We will be taking off in half an hour. However, if you prefer, we can skip pre-flight controls and depart immediately in order to arrive at our destination more quickly."
If as a consumer, you expect the highest quality in the products and services you receive, what makes you think you are exempt from delivering the same quality to your consumers? Of course the airlines also want to maximise their profits by minimising their time on land, but would you consider this as an excuse for them forcing their pilots to skip the pre-flight checks?
Change should start now, and it starts with us
In my many years as a software architect and agile coach, I have consistently preached about quality of delivery. And I was accused of being childish and ignorant of the realities of the "real world". The people who accused me of doing my job were the same people who complained that a small change takes too much time due to accumulated technical debt, whilst at the same time arguing against the Quality Gate I created to reduce technical debt.
Do the right thing and do it right
Developers usually feel trapped between the legacy code with a high technical debt and the non-stop urgent demands from consumers (or rather from people thinking that they are representing the consumers).
Doing the right thing is the main idea behind every agile framework. I’ll be using the Scrum terminology here, but the ideas apply to all agile frameworks. Product backlog is one of the artefacts of the Scrum framework, meaning there should always be things to work on. There’s also a Product Goal which is the commitment of the backlog. So having non-stop demands is healthy for the product and the team developing it. But not all demands are both “urgent” and “important”. A good product owner should prioritise the demands with “important and urgent” ones on top, followed by “important but not urgent”, “urgent but not important” and “neither urgent nor important”, keeping the pressure on a healthy level.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This is one of the principles behind the Agile Manifesto. It clearly states that the velocity of the team should remain the same over time, avoiding dips as well as spikes. Spikes cause exhaustion and inevitable dips in the end. It is the product owner’s responsibility to manage urgent and important features without causing unforeseen spikes. Naturally, some markets require more urgent work than the others, but the team can adapt itself to this situation by shortening its sprint duration.
This article is not for product owners, but there is still a reason I’m talking about prioritisation in an article aimed at developers. We, as developers, should support the product owner in deciding what is important and urgent. Business metrics like usage ratios of features, user journeys and business errors preventing users to achieve their goals on our product will feed the product owner enough data on top of their market knowledge to decide correctly.
Doing things right is a responsibility of developers. Definition of Done is the commitment of the increment, and it ensures that the product’s quality remains the same or even better over the time. It’s developers’ responsibility to vocalise the need for updating the Definition of Done if they believe the current definition is not contributing to the overall quality well enough.
Also it is important to discuss non-functional requirements deemed important by the developers should be discussed with the product owner thoroughly. This also includes transparently sharing the technical debt metrics with the product owner and offering remedies to resolve them and helping the product owner add those remedies to the product backlog with a proper priority.
It is human nature to shift blame, and it is usually the corporate culture that encourages this behaviour, which is a topic in itself. But quality starts at the individual and team level, and there's a lot to do there. We can not even discuss the impact of the organisation on quality if there is no understanding and desire for quality at the team level. A developer should never compromise on quality and try to resist pressure from his colleagues, the product owner or even his boss. The same goes for the team level. They need to keep their quality above what they have agreed for the Definition of Done and always set higher goals than the organisation's standards. Then it is the responsibility of the organisation to encourage and support this mentality, which it rarely does. In Part 2, we will look at patterns and anti-patterns at the organisational level that affect quality.
Previous article
