If you asked a random person the question “are software developers rational as a whole”, you would very likely get an affirmative response. That response would show ignorance of the periodic pseudo-religious movements within the industry.
One of the current religions is test-driven development. If you write tests after you write the actual code that performs the task at hand, you are now the weird one. If you don’t write them at all, you’re a veritable sinner.
All praise the current system. There is no better system than the current system. There are no excuses not to use the current system. The current system is almighty.
The Twitter congregation
I saw an interesting tweet last night that motivated this article. The tweet was by a pretty well-known tech writer and it went something like this:
The excuses people use not to practice TDD:
- It consumes too much time
- It makes no sense to write tests first
- You don’t need automated tests
- It’s too hard
- My project is too simple
- It leads to bad design
This is a great tweet because it’s indicative of the sort of axiomatic thinking that pervades these circles. Dear believers, those aren’t excuses. Those are reasons. When you classify arguments against your point of view as excuses made by the lazy and the ignorant, you deny all possibility that you just might be wrong.
It’s not just one tweet, either. It’s a whole congregation of people who believe that TDD is a panacea and that non-believers are derelicts of a bygone era who must be ridiculed and chastised.
In the comments, a man had the audacity to ask for proof that TDD works. The answer, as might be expected when you attempt scientific inquest on a religious topic, was dismissal, ridicule, and the inevitable “well you can’t prove that it doesn’t work”.
All praise the current system. There is no better system than the current system. There are no excuses not to use the current system. The current system is almighty.
The tech pantheon
Back in 2012, I was coding in PHP on a Windows machine. I was lectured by 
The Declining Value of a University Educationmore ‘educated’ peers that I should use Linux and switch from PHP to something ‘better’. My argument in response wasn’t that Windows is better than Linux (it’s not). It wasn’t that PHP is the best programming language either (it’s not). My argument was simply: it doesn’t matter.
In most cases, it doesn’t make much of a difference which server and which programming language you use (let alone which framework). What matters most, I’m afraid, is how good you are at your job.
The outcome? I 
Five Lessons I Learned Bootstrapping a Fantasy Sports Companybuilt a fantasy sports game that gathered hundreds of thousands of users, ran it for a few years, and ultimately sold it. My educated peers spent those years scuttling to keep up with the trends and switching from technology to technology in search of the one (they’re still looking, by the way).
There have always been technological gods to worship. The current ones are just the latest incarnations. In five years, there will be a new god. Then another one. And another. In the meanwhile, denying praise to the existing deity will not be tolerated.
All praise the current system. There is no better system than the current system. There are no excuses not to use the current system. The current system is almighty.
Man on the moon
In 1969, humanity took its first steps on the surface of the moon. The software that enabled this mission was built in assembly language. We’ve all seen the photos of Margaret Hamilton next to a pile of papers taller than her. Those papers contained the logic required to guide a spacecraft on a 240,000-mile journey, land it safely on a giant moving rock in space, then bring everyone back in one piece. At stake were the lives of the astronauts, the future of NASA, and America’s position in the Cold War. Its performance was verified by having two teams build the same features in parallel and then compare them.
If this approach can make humanity a spacefaring civilization, then your to-do application doesn’t require automated testing, containerization, and a special framework. You may well be inclined to use all of the above, and that’s perfectly fine — but it’s not required, it won’t necessarily make your product better, and you definitely shouldn’t berate others for using a more barebones approach.
All praise the current system. There is no better system than the current system. There are no excuses not to use the current system. The current system is almighty.
Praise where praise is due
Tools make our life easier. That much is true. It’s also true that not all tools are created equal. Some are more efficient than others. That doesn’t, however, mean that they are adapted to every situation. A pneumatic drill is a powerful tool, but that doesn’t mean we should use it where a prick of the needle would do the trick.
I’m not denouncing test-driven development (or anything else, for that matter). I’m not anti-testing, I’m anti-dogma. In programming, as in life, dogma is harmful to progress.
Tests are useful — but you don’t have to write a test for every scenario in every project.
TDD can be useful — but not always, not in every team, and not for every product.
Docker is great — but you can do without it and there are alternatives.
Cloud hosting is convenient — but you can still host most things on just about any regular hosting server.
All praise the current system. There is no better system than the current system. There are no excuses not to use the current system. The current system is almighty.
Conclusion
As an entrepreneur, the best thing you can do is build what you have envisioned using whatever tools are most expedient.
As a freelancer, the best thing you can do is build what your client wants as efficiently as possible.
As a team leader, the best thing you can do depends on the individuals within your team.
Sometimes, it’s not worth learning a new programming language to gain a 2% increase in performance. It’s usually not worth adopting a whole new paradigm that will flip your team’s workflow upside down based on inconclusive evidence.
Tune out the chatter, consider what’s best for your team, talk to everyone involved, weigh the pros and cons, and make reasonable estimates about the outcome before you make any drastic changes to the way you do things.
Don't miss the next blog post!
I publish a new blog post every Wednesday. Join the newsletter to get:
- One valuable email a week.
- Zero spam.
- Exclusive content not found in the blog.
- Reply directly to me with questions or feedback.
Use the form at the bottom of this pageon the right to join the newsletter.
