It seems like every few months someone announces a new development methodology that will result in drastic improvements to software production and is the "one true" way to develop software. Perhaps creating your own development methodology is a rite of passage that all mindful developers must pass through. You may be reading this and thinking "Oh great here we go again. Some nutjob is going to announce his new development methodology." Well, I'm sorry to disappoint but I am not going to announce a new creation today. The development methodology that I'm introducing today is not one that I created but one that exists naturally in the universe. I am not its creator. I am only itsdiscoverer and spokesperson. This development methodology exists as a fundamental building block, like atoms, quarks, energy and bacon. Today I'm proud to announce a development methodology I lovingly call "Testosterone Driven Development".
I would love to tell you about how Testosterone Driven Development will change the world, but that's unnecessary. It already has. I'd love to tell you about how it will become so popular it will sweep the globe, but it already has. It's only a matter before you encounter this methodology, so you better start studying now, or you risk being left behind. There's a chance some members of your team are using it already, but perhaps, like the spinning of your CPU's fan, its presence is so constant and unchanging that it's become invisible to you, only noticeable when you focus your caffeine sharpened senses on it.
As your humble guide, I will share with you the gospel of Testosterone Driven Development (hereafter called TDD, because no one has ever used that acronym before).
- TDD'ers never profile before optimizing.
Because you have intimate working knowledge of your program, and all of the libraries it uses, and the libraries they use, and the kernel your program is running on, and the machine code instructions that will be generated by the compilers and the number of cycles each machine code instruction will take, and the scheduling of threads, the lock contention, the interaction of the garbage collector, and its I/O latency. Since you have all of that in your head, you know exactly where the bottleneck is and can optimize it by injecting hand written assembly into your code. Anyone that doesn't hold all of that state in their brain is a wuss and should not be allowed on your team.
- TDD'ers never compile before pushing.
Your fingers are so full of testosterone that they simply can't type code that doesn't compile. In fact your code is so manly it will even compile in the presence of syntax errors. Does anyone really think the 98 pound weakling of a compiler will even be able to emit a warning with your code? NO!
- TDD'ers never write unit tests.
Unit tests are for developers that write bugs. TDD'ers don't write bugs. If you think your code needs unit tests, you should put your keyboard back in your purse and go home.
- TDD'ers never write comments.
Comments only encourage the weak to modify your code. You don't want them leaking any of their estrogen on your manly code, so don't encourage them by adding comments.
- TDD'ers always use global variables.
Your testosteronian influence is global. Why shouldn't your variables be too? Yes there are some little pre-pubescent boys that can't hold global state and every execution path that could mutate the global state in their tiny immature minds while simultaneously hammering out studly man code. But do you really want those little boys hanging around while you emit scorching horomone fireballs from your oral orifice every time you vocalize your algorithm in your sultry Bary Manilow voice? Of course not! Their screams might interrupt your flow and their tears might fall into your keyboard. Or worse, your Red Bull.
- TDD'ers never use third party libraries.
You don't wear your Mom's underwear now do you? Why not? because they are filthy. You know third party libraries are filthy too. They were written by people who are dumber and weaker than you. You know that third party libraries only work for other developers because they don't write real software.