Why Test-First Development is So Damn Hard
I wrote my first program when I was a kid—many, many years ago—not on a computer but on a piece of paper. How did I know if it was correct? I didn’t until my father’s buddy, an experienced programmer, read it. He interpreted my program in his head and gave me back my paper. It was littered with red colour.
This was the first time I saw a human brain working as an interpreter and compiler. This was first time I’ve seen how testing works. Testing? Yes, thinking. Deep thinking actually!
Since that moment, the spark of curiosity lighted in my brain each time I built programs. How can I create something without testing it first, without knowing what I want? How can I “load” a program to my computer without causing a disaster? How can I build something without measuring and checking the progress?
Over the years of working in the electronic, automation and software industry, I have always questioned the quality of work and the quality of products.
However, my mentor, John Arundel, recently captured the essence of technical excellence in his article Introduction to Test-Last Development - TLD. Most books about quality, testing and engineering didn’t impact my thinking process as profoundly as the article.
So, what are the unforgettable pieces of advice he gave about engineering excellence?
Don’t make me think!
Yes, you hear this right. Thinking is hard. Who wants to do this nowadays? Who doesn’t rush to build software, ship and collect the paycheck? So, don’t bother about designing the product first. Just ship! Ship fast and break things!
Real programmers don’t design stuff
Any idiot can write a test for something that already exists! Any idiot can measure the size of some product and then sketch and adjust the assembly manual. Thinking, writing modelling first, before building the physical thing, is damn hard! Who wants to do this?
Just practice TLD - Test-Last Development
It’s the most straightforward engineering approach. Just write something, copy from Stack Overflow or take some ChatGPT vomit. Mesh it. Stir, fry and ship it!
Next, collect a bonus from management for meeting deadlines! Customers? Don’t bother. You may not be in this company when they come back with questions.
Be a hero in management’s eyes
What do you do when they ask questions about why development takes 4 sprints instead of 1? Tell them something technical when they start bragging about speed and performance reviews. Something in line: “Because the main memory frobulizer is pass-by-garbage, and we use pointer crapulation in most of the packages, we experience the slowdown.”
You will have peace of mind and you will be back to writing, compiling and looking busy. In the end, you shipped the feature, the products sell fast, and the share prices go up. What’s more important?
Relentlessly practice the all-purpose test excuse list
You can still use the Test-Last Development delay practice if you must write tests! Not everything is lost. You wrote the first test. It uncovered serious bugs in the product. You can’t progress. Each step will take a long time! Besides this, writing tests is boring, and clients don’t pay for test code. They pay for products!
The goal is to reach 100% test coverage
With the industry’s current state, it’s easy to ask the “AI” assistant to generate all the tests, isn’t it? Who cares if the product doesn’t do what it’s supposed to do? We can always reach 100% test coverage! It’s not a big deal.
Imagine bringing your old, unreliable car for the yearly technical inspection. Then, the mechanic will adjust the generated tests to pass! How wonderful! Your car is always fully functional! Anyway, you plan to sell it next week.
The fight for quality is over. Don’t listen to folks talking about test-first designs and development, quality, and reliability. Test-first design is hard—and hard is bad. Follow the straight and easy path!
That’s it. Yes, software crafters sometimes should stop, step back and reflect. What is a better way to do so than to look at our work from a different perspective?