Software Best Practices

As I'm working on NValidate (an open-source parameter validation library), I am constantly thinking of newer tests to add to the library. For example, today, as I was working on production code, a thought for a new test occurred to me because I was constantly writing the same test over and over again that looked something like this:

   If myParameter = 0 Then Throw New ArgumentException(...)

The current NValidate test would look like this:

   Validate.That(myParameter, "myParameter").NotEqualTo(0)

But it occurred to me that I could simply add the simple test:

   Validate.That(myParameter, "myParameter").IsNonzero()

The idea is that I want to make the tests as easy to read as possible, and that's pretty darned readable. The problem is that I can see where it might get out of hand pretty quickly. (I mean, doesn't that kind of necessitate an IsZero test to match it?)

So here's my question for you folks: how do you deal with that sort of fuzziness? Feature creep here might be a real concern. On the one hand, the initial set of tests supported by NValidate need to be fairly complete or it won't ever get off the ground. On the other, if I don't stop futzing with it and release something, it still won't get off the ground.

I've released the initial set of tests on the NValidate site (http://www.nvalidate.org/testmatrix.aspx). I've since added a few tests. I suppose that I'd be really interested in knowing whether or not I need to just wrap up what I have and release it.

Any help is GREATLY appreciated.

 

Firstly I would like to say that I think what you are working on looks really good. I like the idea of making parameter validation (always a good practice in my opinion) easier and I love your application of fluent interfaces.

In answer to your direct question I think that you have more than enough functionality to justify an initial release. Having said that I would caution that your code needs to be reasonably stable, documentation needs to be complete enough to allow people to use your library and you need to be prepared for the time and effort that will go into supporting your initial release. Whether to release isn't just about what features you have!

In general I think that releasing something early has a number of benefits and it is worth doing as soon as you have a product that is “at all useful”. The reasons for this are:

• You get early feedback. What do people like? What to users want to see added next? This might change the direction of your project and this is a good thing.
• You get motivated. There is nothing more motivating than having people actually use what you are developing.
• You get testing underway. Real life users actually using your software uncovers defects fast.

Sometimes you need to manage expectations a little: if you are releasing a slow, buggy version to get some initial feedback on a user interface people will accept it as long as you tell them! In general, releasing something soon and often works well in my experience.

David,

Sorry it's taken so long to get back to you. Life's been a bit topsy-turvy lately. Things are settling down now and I've gotten a chance to catch up on things.

It's funny that you mention fluent interfaces. The API for NValidate was originally modeled after NUnit; having the validator methods return the instance of the class was a suggestion from a poster on the Dot Net forums on Google, so that the implementation of fluent interfaces was quite accidental and only intended as a way to prevent the thing from creating an inordinate number of objects. I turned to that particular implementation as a performance improvement. (Go figure.)

In the end, however, I've really taken a shine to the way it's turned out. I recently pinged the forumites again and they put in some really good suggestions. We had to change the name of the class factory from Validate to Demand. Testing with ASP.NET revealed the nasty truth that the Page class has a Validate method on it; the naming conflict was really peculiar. I felt that the onus was on *me* to provide a better solution, not to ask any of my potential users to mangle their code with an extra namespace alias. (Tacky, tacky.)

It turned out really well, though. I think that Demand is a much better name, as it conveys a stronger message. My only regret is that it doesn't wholly jive with the product name now. Still, you have to admit that a statement like this sends a very clear message:

    Demand.That(value, "value").IsInRange(byte.Min,byte.Max);

Finally, I took your advice. I got the code base into "alpha-ready" state, and finalized the documentation. I finally posted it to the web site. It's ready for review. So, in short, THANK YOU. Your advice was just the kick in the pants that I needed.

It's in the hands of the community now. We'll see what they think of its Alpha Release now. I'm treading wholly unexplored waters here; having never been involved in an open-source project, I'm not quite sure what to do next. I suppose, I'll just ask the community.

Again, thank you!

Hi,

Really great to hear that you have produced an alpha-release! I have posted a little bit about your project and the benefits of early and frequent releases on my blog here. Good luck with it and let me know how you get on.

Cheers,

David.