Test Driven Development

Well folks, I'm here today to gripe about Test Driven Development (TDD if you can't live without an acronym). For those unfamiliar with it, the concept is (and feel free to correct me folks), one starts coding the unit tests firsts and implements the various classes/structures one needs to make the unit tests function. By the time all is done, you have a completed, working, and unit tested application. Re-factoring is embraced, heck there's even the TDD mantra: “Red, Green, Re-factor” (which comes from the Nunit paradigm of failed unit tests show up in red, running one's show up in green, and the re-factor refers to moving code around / renaming classes functions, etc to make more sense in one's project domain. Essentially it means, when just the test is written, it will fail as there is no concrete things to actually perform the tasks the test requires. Once you right just enough to make the tests pass, it passes (green) and is now ready to be “integrated” into the rest of the project with minor corrections).

Sounds good in theory doesn't it? Unfortunately, I don't live in Theory (houses are far too costly…) Why only in theory you ask? Well, as I sit here writing some tests so I can actually code the logic at some point, I'm looking at some diagrams of system interaction and whatnot and I frankly have no idea what the hell the tests are supposed to do… I have nothing to test, and using TDD, at best, I'll have tests that work and they will dictate what I build, unfortunately, the business wants me to build something particular. Depending on how well I do it, I could end up with something that is what they asked for, OR I could end up somewhere completely different if my understanding is off or I get pulled into the cadence of test code (vs. application logic which may be optimized for performance or maintainabililty, or whatever).

Basically, what I am getting at is, TDD is helpful when you don't know what you are building. However, if you don't know what you are building, why the hell are you building anything? Your time would be better spent fleshing out the requirements and the design. And before you say it (because I KNOW you're thinking it), “But the business doesn't know what they want, just what they think they want and I need to deliver what they NEED!” Well, I agree, so wouldn't expectations be better managed by working through requirements with the business so everyone is on the same page, wouldn't you know better what you are trying to build? I think so.

So where did it all go wrong? To put it bluntly, <flameShield on=”true”>Inexpereienced Developers are the majority of the workforce, and they often make mistakes (as doing is the only way to build experience, this is expected, and natural (albeit problematic)) TDD is just another way to homogenize the programming workforce to reduce the negatives.</flameShield> The downside is it also reduces the positives of having an “All Star” team. People also cite “quicker to market” reasons as by the time development is done there is something to deliver. This is just slight of hand to avoid the problems of managing business expectations. Cough up more frequent milestones and vi'ola, it looks like things are getting done. Unfortunately in reality, the same time is spent, and I propose, MORE time is being spent with TDD refactoring every pass and of course the final refactoring to align the new code with the existing code (which to be fair mostly amounts to renaming of classes, functions, etc, not so much new coding)

To me it just sounds like an excuse to not have to learn more formal documentation and requirements skills. I think knowing what you have to build is far more important then delivering it quickly. The old adage goes, “You can have it done Fast, Right, and Cheap. Pick any two.” This technique addresses the disconnect between the developers and the business that employs them who know very little about software development (think Business Programming here, not so much Software Development shops 😉 ) I firmly believe a much better approach is to teach the business what they need to know to manage software development projects, because we as developers don't have that skill, our magic is programming and archetecting, management is for the pointy haired boss types.

 Ok, I'm done. My apologies to anyone I've offended! Please feel free to correct me, I'd love to hear your thoughts!

I should probably mention Martin Fowler's book, “Refactoring. Improving the Design of Existing Code” as it's pretty good, although seasoned developers will likely know a lot of the items in the book, other books seem to reference this one (for example, “Refactoring to Patterns” by Joshua Kerievsky”)

-Regards!

www.Quake-Revolution.net

Due to a DNS registrar issues, Quake-Revolution.com is now available at www.quake-revolution.net and will be returning once the registrar issues have been resolved.

 The team apologizes for the inconvenience and offers a reminder, “No good deed goes unpunished” 🙂

Regards!

Reactance 1.3 Beta 7 Released

Mostly a maintenance release to address a bug in the off-hand grapple. Thanks [CL2] R@ancid Me@t (CL2 Clan Site) for pointing it out. And thank you Evolution (from Quake-Revolution for pointing out it was likely a prediction issue (damn you Q3!)

What happened to 1.3b6 you ask? Well, it actually never happened. It wound up fixing the bug in offhand-grapple, but was no where near the real solution :-/ (they all can't be gems folks…) So, it was sh!t canned in 1.3b7 was born.

Here's a snippet from the ReadMe :

2/28/2008  -Monkk: Fixed broken off-hand grapple. Thanks Evolution for
                 aid in locating the problem and R@ncid Me@t of CL2 for
                 finding it (bastard :P sorry it took so long to fix...). While I
                 was in there I added 2 grapple related cvars (server
                 controlled): mod_grappleDistance and mod_grappleSpeed.
3/2/2008    -Monkk: Completely redid the offhand grapple to not force
                 the sound on the weapon itself, but instead on the hook
                 that is being fired. When one is attached to the wall with
                 the offhand grapple, the grapple continues to make the
                 sound. You will also notice the sound originates from the
                 hook missile. This is due to having no weapon actually firing
                 it. The normal q3 grappling hook weapon gun acts the same
                 as it always has. Also added cvar for
                 mod_ambientWeaponSound which will disable the sounds of
                 the RG, LG, and BFG

http://www.reactanceunlagged.com to grab it =]

Regards!