Wild Theory Driven Debugging

Scott Berkun has an amusing post on ADD (**shole Driven Development), a parody on TDD which occurs when the technical decision-making process in an IT Shop is hijacked by an over-bearing personality who always manages to persuade people into doing things a certain way because the cost of opposing that person is simply too high.

The comment section of this blog post is definitely worth reading and coins some other noteworthy processes that are rampant in the industry, such as BTPWAL (Blame the People Worked and Left), BDD (Buzzword Driven Development), and IAAD (It’s Almost Done Development).

This post even prompted me to respond with my own new methodology:

WTDD (Wild Theory Driven Debugging) – A methodology that enables developers to quickly resolve debugging tasks by blaming erratic, intermittent software failures on external forces that are not immediate under the developer’s control (i.e. firewall, network, test domain, server issues).

This approach is extremely lightweight in that it requires no direct physical evidence such as logs, tracing output, or KB articles to support the assertion. When used in conjunction with ADD and loosely related coincidences, it has the added benefits of allowing you to sound smart while simultaneously weaseling out of any significant debugging effort.

6 Comments

  1. Dewayne Christensen July 11, 2007 9:57 pm 

    I can’t tell you how many times I’ve had this lesson reinforced: Assumption #1 of the well-honed developer is “It’s my own fault.” (by watching _other_ people make the opposite assumption, of course…)

  2. Robz July 17, 2007 2:01 pm 

    If something worked before you released and now it doesn’t, it’s pretty peculiar to think something OTHER than your code caused the problem. The correlation is just too strong to deny…unless you never take responsibility, or you have a big enough ego to think everything you write walks on water.

  3. YG September 3, 2007 6:30 am 

    I’m not sure if I get this methodology. If the the problem really isn’t under the control of the developer, then is it a good practice to pay that developer to “debug” his software in an environment that he has little or no control? (And that really isn’t debugging, that’s trouble-shooting). Sounds like the reall problem in the WTDD theory is not providing developers with a stable environment to write and test their applications.

  4. Russell Ball September 3, 2007 8:05 pm 

    Perhaps “Under the Developer’s control” wasn’t the right phrase to use here. I was more referring to the situation where you have a segregation of responsibilities so that developers only investigate application related issues and an IT Pros will investigate OS or network problems. It is not that a developer is powerless to investigate and fix these issues, but that he or she could decline to do it because they feel it is not their responsibility because underlying problem does not lie on their side of the fence. Although some problems can be resolved faster with this type of segregation due to greater expertise, I think most problems get resolved much more slowly because of the “hot potato” syndrome where each group claims that the problem exist on the other side of the fence. I can accept that people can legitimately disagree about the cause of an issue, but I would at least expect each side would provide evidence for a theory such as event logs, tracing tools, diagnostic software, or Knowledge Base articles before throwing up their arms. My frustration comes into play when theories are tossed around that make it the other person’s problem without any effort to first verify the facts.

  5. essaycapital April 17, 2013 2:23 am 

    This post is awesome! Thanks to the author.

Leave a Reply