written by owen on 2017-Nov-29.

People have been trying to push this meme for so long its ridiculous. It is almost like the time when these same people tried to postulate that OOP was the "one true way" to code but instead just kept changing the goal posts year after year until they just stopped talking about it all together. Side stepping whatever issues that arose. Now when the people who ordain "fashionable jargon" realize that TDD is not rising to the front of the hype train fast enough they resort to chastising anyone one who is not in lock step with their opinions. This latest attempt is to associate the use of TDD with the entire software development as a profession. If (and that is a big "IF") TDD can prove its worth then it will but do we need cheerleaders that preach it from hills and high chairs? But of course it can't. All I can say is that it seems like low hanging fruit. Folks, if you're coding, and not writing tests, simply put, you're not a professional and you're not going as fast as you could be. Lawyers have other lawyers check over their stuff. Accountants have double entry bookkeeping.

In a world full of buggy, auto-updating software, embedded advertisements, and cloud services that become insecure the moment you start using them - the last thing we want is to shackle new developers with a false sense of security by telling them TDD will make them professional. No matter how many tests you have you will not be saved from badly written code, missed deadlines and total rebase over a weekend. We need new and better code, not new religions for writing old code.

People in the business of making memes and mantras are trying to by impose their workflow unto others in a kind of elitist push to make the world a better place. Next year it will be Elixir or CSS modules or GO or Bitcoin or some other made up metric for standardizing the programming workflow into some kind of cult. What really matters is the problems you solve and NOT the stack that you use to solve them. The devs that create more problems than they solve and write un-maintainable code will do so irregardless of stack, tests or build tool. Everyone is responsible for the code they write and TDD will not save you from that mess you have written. Of course it will make a nice bullet point on your marketing brief.

XML all over again

Oh lets not forget XML. XML was suppose to make all the world's data interchangeable and editable by human beings in case they somehow got root access to your production environment. And on a whim decided to dick around in your shit and make changes to your hardcoded references. But then we took the XML thing too far and started to dump logic and all sorts of crap into it until it became a buggy un-maintainable ginormous mess. That is what programmers do, we take things and push them to the limits until they break. What is life without choas?. XML was everywhere and now its JSON, what will it be next?

Tests have been around forever, even before we had whole separate departments of people who would painstakingly test every piece, section by section just to ensure that everything worked as expected. Even today with the best tools existing-ever, there are Android devs that still test their code on target hardware because no matter what you do something in the operating system will end up causing the code to crash. This is a whole other problem of externalities.

How we deal with externalities

Now we have modern browsers so no need to test in anything besides the latest chrome, no need for fallback, javascript all the way down. Because if you are not using a modern browser you might as well be dead.        Post modern javascript babies are everywhere. Web dev programmers complain about one set of things while oblivious of anybody else in the programming field who have other concerns such as hardware, performance or compatibility. Oh your browser is not modern enough to handle my fading buttons! You need to upgrade your operating system! When the web devs are not being Agile they are trying to destroy SQL databases because they are a pain to test and do not work well with source control and one click build scripts. Document stores were all the rage at one point. Whenever there is something that is incompatible with the build environment it must be destroyed or replaced with something 10x as complicated.

Where is it all coming from

If you write enough code and you wear you headphones at the disco you will begin to see patterns in programming; you have punch cards then assembly and then we kept making languages simpler and simpler until we started using multi-core processors because programming was so simple we had too much code and physics was not playing nice. Today we have software which is so large that you cannot even compile it on a regular computer. Imagine compiling 200 mb of source code! Code is so easy to write that we actually have too much of it and we are now thinking up ways to write more of it faster but what we fail to realize that some of these problems are caused by continuously focusing on the wrong things. When OOP was on the rise everyone said it would solve all our problems yet it only resulted in spaghetti code, then we tried to solve it with factories and MVCs, interfaces, the list goes on and on. Now we are trying to solve OOP with TDD. We have so much code now that we have no idea what to do with it, we open source it, give it a way for free but no one wants to work on it because its BORING.

So you have a tonne of code that is glued together by random people who have already left the company. what do you do? Write mock objects! Run the tests! Tests pass! Move fast break things!

I am not even going to mention game developers and low level micro-processor programmers. I am loading a 10mb file into 5mb of RAM at runtime - how is TDD going to help me solve this problem? Answer: Its not going to solve anything. They have no time to install CSS Modules so they can add 10 seconds to their build time. Their concerns are memory, input and output. These are the problems they are trying to solve. They are not interested in the struggles of millions of new programmers who have no idea how to build a crash-free rocket-ship or a flying car using Node.js after completing a 2 week online bootcamp. If you want to solve those issues then solve them separately.

Conclusion

It is all about context. Yes TDD is good for somethings. It would be nice to have an infinite regress that you could solve instantly with the push of a button. Or maybe you have a large team of disparate people working remotely on the most bloated piece of crap software in existence and you have great tests. But please do not try to attach you workflow to wide and diverse industry of people who are simply trying to solve problems before they die. Only time will tell if TDD is a solution to anything besides the problem need to hire testing teams and spending hours looking for bugs. But at least make it solve some current problems instead of creating a separate maintenance nightmare for everyone.

permanent link. Find similar posts in Articles.