Thursday, December 4, 2008

YAGNI and when

I struggle with YAGNI frequently (You Ain't Gonna Need It). But, recently I had some success with just being draconian about. Not adding features unless I could justifiably say "this is adding value X for Y need".

Today, another developer I was working with gave me a bit of a conundrum. We were expecting one of two values from a column in a database (Say "S" and "E"). However, in very very rare cases we could get another couple of different values (Say "X" and "C"). They would likely never come up into our code, and if they did, the rest of the corresponding data would be completely incorrect, and the data would go through the normal paths of incorrect data.

So in this case, should I adjust the code to handle extreme corner cases, that don't effect the actual outcome of the application, but could give some fidelity into logging if an "X" or a "C" actually showed up?

I think YAGNI in this case is telling me not to worry about the C and the X, as they don't actually effect the end result and we have no need for that level of logging fidelity at this time(and changing the where block to exclude the bad possibilities should be enough). But it did give me pause to just leave those corner cases floating out there untouched.

It made me think a bit how in reality a YAGNI style approach probably helped contribute to the justification of y2k problems, and to a degree this was the same issue (which was this other developers contention).

However, I'm pretty certain with modern languages and patterns one could stick to YAGNI and avoid a y2k style mess.

No comments: