You Might Need It

YouMightNeedIt, but are you sure you aren't BorrowingTrouble?

In YouArentGonnaNeedIt, the following statement is made:

: Sorry, I fear you do not yet apprehend our meaning. XP Masters don't break XP rules, except in error. (Most of us are only human.) One rule, YAGNI, is never to implement functionality for which you do not have a current need.

I'm interested in comments from "XP Masters" about the following situation.

In a body of code I've been asked to maintain, there's a class of error that occurs frequently: The programmer has forgotten to add client-side validation code to forms, or the code isn't what's specified.

Months later, I am assigned to come up with a new validation scheme. Remembering the past problems other programmers had in this area, I consider adding a new feature. This feature--enabled only at development time--brings up a dialog box listing form fields that don't have validation code, or (if possible) fields that seem to have incorrect validation code.

No requirements document asked me to add this feature, but I did so anyway because I remembered the past problems caused by its lack. I justify the time spent by considering the future time we might save. I obviously can't calculate that, but I can demonstrate how much time was wasted in the past, and use that to illustrate the problem.

Am I applying or violating ExtremeProgramming here? Does ExtremeProgramming address tools like this that are built and enabled during development to help developers?

-- JohnPassaniti

Sounds like an excellent solution to me. Could you even write the dialog as a UnitTest, so when someone tried to check in code without validation the test would fail?

The way I practice XP is exactly to try to make the mechanics of my work easier so I can get back to serving the customer. To avoid spiraling off in self-congratulatory flights of tool building, I just make sure that it stays under the radar and the team keeps delivering iteration after iteration. --KentBeck

Perhaps "need" includes things that the developer needs to GetThereFromHere?, even if they're not in the requirements document. UnitTests aren't FunctionalRequirements, but they're still needed to fulfill NonFunctionalRequirements for quality. One has to be always careful of self-congratulatory flights of tool building.

You wrote that you were assigned to come up with this new validation scheme as a response to "a class of error that occurs frequently." If that's true, someone decided your fix was needed, so you addressed it. This doesn't violate YAGNI.

Validation is always a difficult problem, but I have found that users prefer you to err on the side of too little validation, rather than too much. Testing departments, however, tend to take the opposite view.

We support our own help desk, and users accept if they enter incorrect data that something wrong may happen. If, however, the validation prevents them from entering correct data, that is a major problem. Yes, put in checks so the systems does not crash or lock up on typos, but it is better to put the checks in to handle actual conditions rather than predicting where to add validation.