delphiXtreme

So we have this whiz-bang app for tracking whosits and we’ve decided we need to also track whatsits. So, we need a list. We could just use a string list for now.

“But wait!”, you say, “We should use a custom list object for this! You know very well that you’ll need it.”

Maybe. Maybe not.

You can’t know today what you’ll know tomorrow. That’s why we have the precept “Code and design for today”.

We’ve got two different approaches. Just so we have a point of reference lets refer to the custom list decision as BDUF (big design up front) and the generic list as YAGNI (you ain’t gonna need it).

Let’s stipulate that we decide upfront that we need this custom list object instead of making due with a generic one. Let’s also stipulate that after 10 “units” of production code we’re going to later discover that we took the wrong approach and have change directions. How would it look if we compared the BDUF approach with the YAGNI approach? Let’s see:

Let’s say that …

Pluses represent time working on production code (code that’s being continuously integrated and reviewed).

Question marks represent the phase during which we found out we took the wrong approach and have to change direction.

Minuses represent the time developing the custom list object.

Here is the time line for BDUF approach with the custom list object:

1234567890123456789012345678901234567890
----------++++++++++??????????++++++++++

Here is the time line for the YAGNI approach making due with a generic, non-customized list:

1234567890123456789012345678901234567890
++++++++++??????????++++++++++

In both cases we get 10 pluses before we find out we have to change approaches, 10 question marks for changing the approach and 10 more pluses to finish the work.

Why would YAGNI finish first? Because we can find out that we took the wrong approach earlier. Why? Because the code is getting into the system faster and being reviewed more often.

Deciding up front that we need this or that is a common trap that we as developers fall into. It’s easy to decide that we know everything we need to now and begin making plans based on that information. I’m not saying don’t make plans. I’m saying to commit to as little as possible. Make your plans as short range as you can. In the above time lines we had to have 10 “plus” units before the customer says “Oh, when I said A, I meant B”. The faster we got to the tenth plus the sooner we could get the customer feedback.

So … release early, release often, and code for today.

XP