You're Cheating Your Employer If You're Not Doing TDD
Let's man up and eliminate manual steps in software development
Software development professionals have achieved a somewhat mystified status. Up until very recently, most non-technical people were in awe before software developers and software engineers (the advent of Generative AI, in particular ChatGPT, have lessened that fascination; nevertheless, the mystical aura surrounding software development still prevails).
In the early days of my software development career (we’re talking 1990s), people would often wave their hands and say “OK, Alex, you go and do your magic, and let us know when the app is ready for demoing.” If that’s not a sign of believing in something magical, something special, something mystical, I don’t know what is.
We became cocky
Too much pride, too much hubris, made many of us cocky. We realized that we almost have a license to do as we please. Which is a fine position to be in, don’t get me wrong. However, since the desired results weren’t coming out as our bosses were expecting, a change was afoot.
Enter XP, Agile, standup meetings, etc.
To address the serious issues with projects taking forever and being alarmingly over budget, the industry was doomed to undergo radical transformation. First the Extreme Programming (XP), and on the heels of that, Agile Manifesto. Then Google introduced daily standups to tighten the reins and to make software professionals more accountable.
Suddenly, the joy and the fun of software development turned into drudgery.
Where is the slowdown?
I worked with many CEOs, and pretty much each and every one of them confessed to me that they don’t understand why is software development so unpredictable and why is it always taking so much longer than expected? I always have a very simple answer for them: the reason it is so is because software developers like to do everything manually.
Think about it: while we base our profession on automating other people’s chores, we do not automate our own chores. Not only that, but we actually take excessive pride in our manual chores. We hold our manual chores to be the very essence of software development.
What are those manual chores that we are so attached to? Let me count them:
We make a change to the codebase & save the change
We then manually compile the changed code
We then manually configure the changed code
We then manually build the changed code
We then manually run the app
We then manually log in to the app using some test credentials
We then manually navigate the app to the area where the changed code is now accessible
We then manually type some test data, submit the test data, and manually verify if the app behaves as expected
If the app behaves as expected, we manually log out and then manually log in again, this time with different test credentials, to retest the working of the app (rinse, repeat)
If the app does not behave as expected, we start a debugging session and place a break point on some statement in the changed code
We then manually run the debugging session, stepping through the changed code, inspecting the values produced by the changed code
Needless to say, all those manual activities are eating up all kinds of time. Especially if we dive into debugging sessions, which are known to often take long time, sometimes almost the whole day!
Let’s ask ourselves now: who is paying for all that wasted time? Our employers, that’s who. But they’re barely aware of this horrendous waste. From their perspective, they hear our keyboards clacking and they assume that we’re hard at work, writing useful code. They have no way of knowing what it is we’re actually doing while we’re banging on keyboards.
I say that’s a suboptimal, nonprofessional way of working. Wouldn’t it be more honest, and more professional, if we were to eliminate all that waste and give our employers the real value for their money?
You may answer “yes” to the above question. But then people who answer “yes” sometimes get confused — OK, we’d like to avoid wasting the time the way you’ve described here, but how do we do it?
The answer is simple — learn and embrace Test Driven Development (TDD). Once you master that skill, you absolutely won’t be doing any of the above eleven steps. There would be no need for any manual chores. You will free up your time to focus on thinking — focus on figuring out how to produce the most optimal design of the software app we’re building. That chore cannot be automated, and that chore should be the activity you will get rewarded lavishly for knowing how to perform.
Imagine how much precious time would you save and how much more value for their money would your employers get if only you agree to learn and master and embrace TDD.
What are you waiting for?