Not only am I a huge fan of software design patterns, I'm also strongly supportive of process in software. Process makes us strong. Process enables us to achieve highly metric-driven quality levels. Process allows us to attend meetings throughout every day, ensuring that any coding time we get will be that much more intense because it is necessarily so short and focused. And finally, process allows us to draw pretty charts and graphs on endless presentations.
Or, as I like to say it every morning when I wake up, "Software Is Process." For without the process, where would software engineers be but in their offices, cranking away code, pretending to be productive?
Now that people have had time to understand and incorporate the important patterns I discussed in my earlier Male Pattern Boldness article, it seems high time to tackle the larger topic of Software Processeseses.
...
Testosterone-Driven Development:
Like its namesake Test-driven Development, which is known for the requirement of engineers writing tests before code, Testosterone-driven Development focuses on testing first. But it does so in an an extremely aggressive manner, requiring every engineer to produce entire test suites, test frameworks, and test scripting languages for every line of product code written, including whitespace and comments. Engineers violating this contract are taken out back where they have the crap kicked out of them. Any code found to have bugs not caught by tests results in the offending engineer having to go three rounds with the project manager (with the engineer being handcuffed and blindfolded during the match). Finally, any bug found in tests will result in the engineer's body never being found again.
Expectations are high from this newcomer to the field, although to date none of the products using this process has left any survivors.
