I find a big difference between walking away from an unsolved bug--particularly when I've done a lot of rip and tear to isolate it--and walking away after I've written a unit test that doesn't pass yet. Leaving a bug unsolved is frustrating, and frustration isn't great for sleep (or for inflicting on other people). To me, an unsatisfied unit test is more of a statement of intent. A unsatisfied statement intent doesn't eat away at me in the same way that an unresolved problem does. And starting the day with that statement gets me moving a lot sooner than having to make up a new statement, particularly before that magic first cup of coffee.

Yesterday I reread your post and realized I had kinda missed the point. *blush* I have some pretty hairy design and code work coming up and I think before I write another line of code on that project (I am currently by lack of choice dealing with other matters) I will be putting together a full set of tests to experiement with TDD. It doesnt make sense to knock something you havent given a proper try of. And if the peace of mind you describe is a possible payoff then its definately worth the experiment.

Many thanks for yet another thought provoking node. (Even if it did take a while to sink in, im kind thick sometimes. :-)


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

Remember TDD doesn't mean writing all the tests up front and then writing code. It means writing a test, making it pass, refactoring, writing another test, making it pass, refactoring... ad completum. Trying to code something given a complete set of tests up front is, frankly, far too hard, the trick is to keep adding functionality in piecemeal fashion.

Apologies if I'm stating the obvious.

I know this goes against standard XP guidance, but I find that writing that extra method for completeness sake is often in of itself a form of advanced test.

I think you are missing the point of You Aren't Gonna Need It. YAGNI is demand-loading applied to the writing of code. If you write code that you think you will need later, but you never use it later, you have wasted your time writing it. Worse than that, you might waste time trying to update the unneeded code to keep up with changes to the rest of the system. Unneeded code obviously should be left out, the only tricky part is knowing which code is not needed. All the code in a system was probably needed at one point in time, but if you go around writing stuff that you aren't even using yet, you create more cruft.

If you have a "supposedly general solution" that isn't, that is just a bug. In TDD, there ought to be a test written that shows the bug. And then the solution can be refactored to fix the bug. If it actually fixed the bug, all the new tests pass and all the old tests still pass. Without those tests, you have less confidence that your refactored solution is actually better than the old solution.

This should be filed under "what to do when YAGNI, but your boss thinks Y are GNI?"

I'm in a new job, been here about a month, pretty much have a handle on my responsibilities, which entail maintaining a bunch of perl (yes!) and some coldfusion (bah!). Whether my boss overestimated the amount of work or I'm brilliant, I don't seem to have enough to keep busy, so today he told me to go write a subroutine to replace some logging code that happens in about 10 of our perl scripts.

The catch is that the requirements for these logs are different depending on which script is doing the logging (despite the fact that they are all being written to the same place), so essentially what I'm doing is writing 10 different logging subroutines and making them all one with some if/else style logic to decide which flavor to use. And it turns out that there is no business reason that he's decided to do this--no client request, etc, driving this. I think rather what is driving it is a) I'm not very busy and b) rewriting code is taken for granted to be good.

How do I have the conversation with him where I say "YAGNI" without sounding like I'm being subordinate/lazy? In my experience, grokking that this kind of anticipatory refactoring can be a waste of time is tricky for many people.

AH

p.s. Writing this post helped me figure out what I really want to do: I want to better define/standardize the logging requirements so that I can write a subroutine that can be plugged in to all 9 scripts. Thank you PM! Your thoughts are still appreciated, however.

Writing this post helped me figure out what I really want to do:

Ha! Perlmonks has been a cardboard programmer.