Announcing Testosterone Driven Development (TDD)

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 its discoverer 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 of time 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).

1. 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.

2. 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!

3. 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.

4. 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.

5. 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? Of course not! Their screams might interrupt your flow and their tears might fall into your keyboard. Or worse, your Red Bull.

6. TDD'ers never use third party libraries

You wouldn't use a junkie's syringe now would you? You don't want their diseased guts in your pristine god-like body. You know third party libraries are nothing more than binary encoded diseased guts. They were written by people who are dumber and weaker than you. You know that third party libraries only work for other developers that don't write manly software.

7. TDD'ers never consult with the team before making big changes

Real men don't ask permission to go to the bathroom. Why would ask permission to make sweeping architectural changes to your team's code base? You know they aren't smart enough to understand your plan anyway, just make the change and let them bask in your glory when you're done.

8. TDD'ers never use revision control

Sure if you start at a company and they keep their code in git, mercurial or some other garbage system, you'll clone the repo and get to work. But you certainly aren't going to merge or check in small changes on a daily or weekly basis, you'll wait until it’s all done. Delivering source code to the team is like giving your mom a puppy for Christmas. Sure you could give her the puppy in bits and pieces and then on the last day give her a needle and thread for her to assemble the fur and guts. But you know your mother will want the puppy delivered in one piece. Likewise your team won't be able to comprehend the brilliance of your code unless you deliver it in its final state.

9. TDD'ers only use revision control to revert other people's changes

OK so there is one and only one reason for a man to use revision control and that is it makes it really easy to throw away others' crap commits. Let's go back to the puppy analogy. So here you are boxing up a puppy to mail to your mother and one of your "teammates" says it would be a smart idea to to shove his pet cockroach right in the puppy's eye socket. Do you try and "merge" the roach into the puppy's eye? Do you try and make the puppy's eye work around the roach? No! You’d never allow someone to do that to the puppy and so you should never allow anyone to do that to your code. If someone commits some code that conflicts with your masterpiece, revert it immediately and then get back to the job of being a real man.

10. TDD'ers don't need bug trackers

Bug trackers track bugs. You don't write bugs, you write beautifully crafted perfection. Setting up software to track the zero bugs you are going to write is a waste of time. Even if you did write a bug just for fun, there are no bug trackers which are manly enough to be able to track the hypothetical bug that you would write. You would crash the bug tracker, and reporting that bug back to the sissy that wrote the bug tracker would crash it too.

11. TDD'ers modify production code

Sure you could first modify the code on your machine and then push the code to a staging area for some idiot to "test" and then push your code to production. You could also not date that hot girl in your class but first date her grandmother, and then her mother and then finally date her. But you testosterone doesn’t play stupid games. It’s laser focused on getting hot chicks and writing sick code. You focus your testosterone fueled laser beams on hand optimizing the code for the production server environment. You make your change to production then go home early to take that hot girl to the monster truck rally.

My hairy man friend. Keep your eyes open for examples of TDD in the wild, your testosterone focused on radiating chiseled bits of code, your Red Bull close, and don't you ever let sissies tell you how to do your job.

Special thanks to Dave Smith for his encouragement, ideas, and understanding of the English language.