I often get asked about the future of NCrunch. Many people cite the sentence at the bottom of the front page ('completely free during its beta test period') as implying that NCrunch will one day be a commercial product. I want to point out that this is far from a certainty and is only one of the many potential paths that NCrunch may one day go down.
I originally started working on NCrunch out of frustration with the existing tools operating in the same space, and as a bit of side-project that I hoped would go into something new and exciting. So far, it's more than exceeded my expectations on the excitement front, with a nice constant buzz of activity and feedback from the people that enjoy using it day to day.
But much more, it's been a fascinating learning experience for me. It's not every day you can find a project even half as challenging as NCrunch. The concept may be simple, but the implementation is far from it. Most projects take their challenges around their integration with other tools, or their algorithmic complexity, or their level of concurrency, or their performance constraints. In NCrunch, each of these aspects is equally very important. Many people seem to think that writing an effective continuous test runner is as simple as just wiring up a test runner and kicking off the tests in a background thread - in reality, that's not even 5% of the problem domain. Just even getting the engine in a working state where it could help on simple projects actually took me several years.
Above all else, the real challenge in NCrunch has been in getting it to work for as many solutions and environments as possible. Anyone who has written a desktop application knows how many environmental considerations there are ... Is the user running Windows 7? Is it a 32 bit processor? Do they have a dodgy anti-virus installed? What about their version of Visual Studio? What versions of .NET do they have loaded?
When you add these environmental considerations to the sorts of complex build and test situations NCrunch is designed to handle, you get situations like: What if this project runs an ILMerge on a post build event? What if it uses an aliased MSBuild reference to a dependent assembly that may or may not be loaded in the GAC? What if the project contains a test that gets surfaced only using an attribute that inherits from a test attribute hosted within another assembly and uses an MTA thread when everything else should be STA?
When many people download NCrunch, they just skip straight past any documentation then go and boot it up against some huge, complex, multi-man-year solution with a legacy of build customisations and frameworks that do crazy stuff, then expect that NCrunch will simply deal with it. It's easy to blame these people for not taking more of a careful approach, but it needs to be expected. If someone picks up a tool they've never heard of before, they usually can't expect to spend 2 hours of their life evaluating whether or not it will work for them. This is why I try so hard to encourage people to report any solution-specific problems as they find them, and is actually the whole purpose of the entire beta program. No software developer on the planet can warrant that such a complex and integrated tool can work in every situation that's used, but I'm damn well going to try and see if I can get close.
One option I have been looking at is to eventually open-source the tool - as this may help many people to solve issues with having it work in their customised environments.
As a concept, NCrunch can move in many directions and solve many different problems. I want to take the time to explore those options before I make any commitments about the future of the tool. For now, I just hope everyone can enjoy coming along for the ride.
Subscribe
