top of page

Why (I Think) Developers Won't Test

Once our new podcast “People AND Tech” (finally!) -word inserted to convey frustration with the speed!:)- is out you’ll hear Dave (Credland-Ballantyne - VP of Engineering of Evora) and I discuss this theme that Bryan Finster instigated with this observation:

While his remark on conferences is spot on, what attracted my attention was the “WHY WON’T THEY TEST?!?” debate which I thought was well put to rest by now with the advent of TDD.

Before anything other, I have to reaffirm my position as a luddite who has barely ever written a line of code and how I am only speaking as an Agile enterprise coach and self-appointed agility anthropologist. I hold it as a point of pride that I’ll be the devil’s advocate voice of consternation when it comes to technology and my comprehension of the matter is intentionally reduced so I can ask “dumb questions”. The entire premise of our podcast is around that. I get to say exactly what I think is happening from a human perspective and he tells me what he sees from a tech one then we bridge them to see what we learned and if it can be applied.

“I don’t get it” -I made a bid to start telling Dave why I’m up in arms about the topic while we were filling up with coffee on the way to our respective morning Scrum of Scrums-

“What’s that? - he tentatively offered knowing this could lead him to be late-

“What even happened to TDD? Thought that was in place and undebatable, that it's mainly why we have to hurry up and crack human relationships so we can do the collaboration that we need to co-create? How can we enter this era of complete automation where we ought to teach our kids how to prompt and how to view life in a way that lets them deconstruct each action into what requires true humanity and what can be made by a machine and yet we need developers to still do testing themselves. Can’t ChatGPT do it?”

“Sure it can, it will eventually”

“So they won’t need to test themselves”

“Well, it’s not that easy…”

“Because if they don’t have a TDD mentality then what they make will be garbage?”

“Yes, partly, this is a meaty one - let’s get this one on record” and he scurried to see if his tens of devs are doing it or not.

Look, I know that the “Why can’t ChatGPT assist in testing to the point that any line of code is shadowed by tests?” questions can be answered with ”It can but the mentality of making something valuable to the consumer, not something that is exclusively fun for the developer to create, must be in place before then to ensure people make things with the intention that they work. That they work like they said they would and that the consumer approves.” And don’t even get me started about how little testing of the latter really ever exists in technology.

But back to developers, if we accept they are at times seduced by the technical challenge and that they give in to the temptation to throw themselves into blessed research, then find a solution and write code while in deep flow, damned be the consequences then how come that is happening. These are intelligent and considerate adults, why would they do that? What we must ask ourselves is “What prompts them to chase the dopamine hit from the research or the wrestling with the problem?”

The answer is - how hard their work lives are in general. And yes, I can hear the eye-rolls from those who have it much harder but that doesn’t invalidate their experience. How much boring stuff they have to do, how much bureaucracy, how much command and control they are suffering and how many times a day are they uncomfortable be it that is mostly caused by social interaction. All the workplace crises at play that we at PeopleNotTech speak about so often. The crisis of leadership, and the crisis of EQ, all contribute. But of all of them, the culprit here is firmly the crisis of engagement. That’s what creates an even bigger need for pleasurable cognitive pursuit. If we factor in how lack of motivation reflecting in work we sense is sub-par can start destructive mental health cycles as they affect the individual’s self-esteem in a debilitating fashion, the need is greater and more complex than we like to think.

Until we help them feel better, safer, more motivated and happier, we can’t change their mentality. Until we find ways to pluck our developers from a sea of disengagement that sees them only perk up for interesting and fun pursuits by balancing their work lives with HumanWork and letting them self-organise when it comes to doing the admin or boring bits so they can get their own brand of adulting in the mix, we can’t expect to genuinely see change.

Maybe we need to accept this x% productivity is all we can ever get. That it’s the top. Maybe if the goal is to have devs most creative and at their best - aspiring to be in the zone most of the time but managing only occasionally- then this one golden day a week is all we get out of them. And maybe - and this is likely but needs to be checked- that’s enough.

And maybe it’s time we reorganised work to support this super intense burst of hyper-focused, super-exciting, specialised, inspired effort and surrounded by the support to make it valuable, instead of condemning it.

But that would also mean those of us whose work can be affected by ChatGPT automation and support would have to become a lot more proactive in figuring out how to better our own lives through its magic by automating out all the tasks that lend themselves to it, while we retain only the ones that require humanity, passion and inspiration spark.

On the other hand, we must all do better. We have to acknowledge our privilege -devs and knowledge workers in general, are considered lucky for good reason. From the outside the job is immensely cushy as intellectual pursuit always appears, but the pressures that the segment experiences can not be overstated. Burn-out, anxiety, depression, AuDHD, are all present and they all make developers even less likely to want to design testable and valuable code. Empirically we also see that developers themselves have a lot of “survivor’s guilt” in the aftermath of the Pandemic and that adds to the general levels of stress increase (just last week it was revealed stress levels increased by 49% globally) and when you have all those negative influences at play, it is little wonder developers are human enough to suffer even if they often choose to do so in silence.

I don’t think we need to necessarily wonder about the “how” or even the “if” of work but about how flimsy and removed from the front of their minds that the “why” is.

I think this is classic Google’s Aristotle findings fail - not enough structure and clarity across the board means teams aren’t obsessed with impact and they probably don’t have any active care remaining about the enterprise, leave alone are psychologically safe enough to discuss it.

Where does that leave everyone? In an ocean of half-statements, lack of genuine care and emotional involvement in meaningful work, political correctness or fear in lieu of focus and solid foundations. And let’s not forget these are people who are least likely to complain but just try and get on with it, barely surviving every day and only momentarily perking up when they can get a scrap of joy at work in the form of some interesting tech challenge to save them from the deluge of useless meetings and corporate fakery. They need the good part. The “in the zone” part. The giddiness of finding something that works and of creating something.

And yes, let’s be honest when in need of instant “commit” gratification, testing is nothing but a potentially soul-crushing stalling exercise because the main goal at the crux of it - products customers love isn’t as clear for devs as it is for the stakeholders.

And there it is. Developers are not stakeholders.

They don’t feel the constant stakes. When it’s dire. When it’s economically terrifying. When the fun tech solution was so buggy it made clients drop contracts. Or when the genius shortcuts hurt the complexity of a license structure in some other way. Or when Technical Debt is created at every corner. And HumanDebt. You get the gist. The ugly bits of the reality of enterprise work that was seen as something business people need to deal with whilst keeping the creative geniuses isolated from the constant stress. This has been an intentional (and in a sense “compassionate”) separation the business has often allowed in knowledge industries because being a stakeholder can be immensely pressurising and consuming as being in charge is stressful. That said, in not sharing and reinforcing the bigger picture to protect them, the business is isolating developers in an executioner-only role. And an executioner has no skin in the game. They certainly don’t have a test-driven mindset.

What are teams supposed to do? Periodic Stalinist-like indoctrination sessions? More NPS checking? (BTW here’s a new fun habit l got into - as soon as l meet a team with profound team dynamics issues l always ask to see their NPS scores because it’s a revelation for all how it doesn’t track, highly advisable an exercise!) Just periodical re-education regarding principles and then forced internal branding to increase “engagement”? Please. As if.

What we do genuinely need if you ask me, is masses of organisational permission and support and then people with enough personal responsibility to keep themselves involved and who engage in Human Work with regularity both at an individual and at a team level because they know it’s the only way to keep each other on track and perpetually motivated enough not to make anything that’s not testable and tested.

What we also need is no one thinking anyone else is a “resource” who has to just execute just as the “resources” need to not think of their work as a meal ticket only,

And lastly, perhaps we need bigger things too? Maybe less insane separation between Prod and Devs. Fewer departments and committees and more bridging between Tech and HR. Less lip service and this utter lack of passion. More overall care. More compassion for each other. More joy.

This is my thesis - we don’t need to repeat they need to design with the test (and I would add, the need to have made something valuable for the consumer!) in mind, we need to create the conditions where they genuinely want to do that themselves- where test-less development is not their only moment of joy and they intensely care about the consumer being delighted with their work- through intrinsic and evergreen motivation reserves born of professional pride, love of the purpose and understanding of impact. In short, let’s hope I’m wrong because if not, they’ll only test when they care.


At PeopleNotTech we make software that measures and improves the wellbeing and Psychological Safety of teams, come see a DEMO.

“Nothing other than sustained, habitual, EQed people work at the team level aka “the human work” done BY THE TEAM will improve any organisation’s level of Psychological Safety and therefore drop their levels of HumanDebt™.”


bottom of page