in Search

Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

I'm getting sick of using "hand me down" tools that are ported from Java to .Net

I'm just ranting. Don't take it too seriously, and feel free to tell me that I'm wrong.

We're working with FitNesse as a means of automating our acceptance testing. I'm pretty happy with the way its going so far, but we've bumped into some annoying crap around lack of support for .Net idioms like enumerations. One thing is very obvious, FitNesse and Fit itself is a Java-centric tool. The original tooling was written I believe in Perl, then ported to Java. The .Net version is a further port of the Java version and it shows. There are far more extensions for FitNesse in the Java version (I'm thinking about FitLibrary). There is also vastly more support, documentation, and samples for working with the Java version. Like so many other tools, the .Net version seems to be an afterthought.

My shop relies very heavily on open source development tools. Almost every single tool we use is a port of a previous Java tool. Sometimes that's fine, but it often means that the tools are a little awkward because they aren't completely adapted for .Net idioms. It depresses me somewhat that development innovation seems to be reserved for the Java and Ruby worlds, with only a trickle down effect for .Net tools. Seriously, how many truly innovative open source projects came out of the .Net community?

I'm not enthralled with the Ajax.Net tool, but I'm excited about the AJAX activity and buzz just because it's being led by .Net developers.

Yeah, I know that Visual Studio Team System is coming out soon as the answer to all development needs. Here's the deal though, the VSTS tools may not be any better in many cases than the existing (free) open source tools. For another thing, does the majority of the .Net community realize that a lot of the VS2005 improvements (refactoring, unit testing and build script integration) are merely creating a rough parity with functionality that's been in IntelliJ and Eclipse for years?

I honestly think the MS would have served the .Net community better by embracing the open source tools inside VS.Net much the same way that IBM and JetBrains has done be creating JUnit and Ant integration directly into their IDE's. I get that Linux is a real threat to MS, but NUnit and NAnt were not. The open source community filled some very major voids in the .Net tooling space that MS ignored for quite some time.

Just for fun, here is a list of hand me down tools we use. Just to drive the point home.

.Net tool	Java forebear	VSTS or MS analogue
NUnit or MbUnit. The bright shining star of .Net tools because it's arguably better than JUnit. The first version was a straight up port, the second version that we use was ".Nettified." MbUnit is genuinely innovative.	JUnit	VSTS unit testing tool. Everything I'm hearing so far says that the VSTS unit testing is considerably slower to execute than NUnit/TestDriven.Net. That matters.
NAnt	Ant	MSBuild contains a subset of the NAnt functionality. It'll be enough for many teams and the integration with the IDE is cool. I think that many teams will use both tools. We depend on a couple of NAnt tasks that are not included in MSBuild.
CruiseControl.NET. CC.NET has grown up considerably in the two years I've been using it. I think CC.NET might actually be better than the original.	CruiseControl	None. You can schedule builds with VSTS, but no true continuous integration support IMO.
NMock	JMock	None
log4net	log4j	EIF or the logging block in the EntLib. I hate the EIF, and log4net gets the job done just fine.
NHibernate. It's okay, but the Java version is obviously more mature by far.	Hibernate	None. I'm still irritated over the ObjectSpaces mess. The EntLib has a new Data Mapper block, but it's mapping against DataSet's. DataSets! The P&P team is actually recommending DataSet's as a business domain!
FitNesse / NFit. I just think that NFit needs to be ".Nettified" to make it a little smoother. We might try to hook on as committers to the project to do this.	Fit	None
StructureMap (Dependency Injection). Also Spring.Net, Castle (EDIT - inspired by the original Apache Avalon, which probably influenced PicoContainer to some degree), and PicoContainer.Net. I wrote StructureMap from scratch in C#, but I was influenced somewhat by the Pico and Spring teams. They broke the ground.	Spring and PicoContainer	EntLib is introducing some limited DI support in an upcoming version.

Thanks you for listening. I feel better now.

Published Sep 06 2005, 02:55 PM by Jeremy D. Miller

Filed under: Ranting

Comments

Second class tool said:

Well when the original tool authors prefer languages other than C# what can we expect? I'm sure there would be similiar issues if the situation was reversed (tools originally written in C# but ported to Java). Rewriting/changing the tool ourselves is about the only option.

# September 6, 2005 1:49 PM

Jon Galloway said:

I won't argue with the pattern, but there are some other reasons for it.

1. Java has been out for almost 10 years, compared with - what, 3 or 4 years for .NET? The above tools are used in mature software development processes, and the Java world has had a lot more time to evolve.

2. In general, the above tools are the kind of thing that comes from Computer Science departments. They have business value to corporate software shops, but it's long range enough that most software shops couldn't justify building these big frameworks and systems as part of their existing projects. They're great to use if they're free, but they probably wouldn't sell well enough as products to justify ISV's building them. They're perfect projects for university comp sci departments, though. The academic world has always been a little biased against Microsoft, so it's only natural that they'll probably be developed in Java and ported.

3. Finally, .NET targets developers who are more likely to reuse something existing if it solves their immediate need than to develop something new. That culture is slowly changing, but I think most .NET developers in need of a logging framework will survey what's out there and pick or port one; the Java developer would see it as an opportunity to create a new logging framework project. Both approaches have merit, of course.

# September 6, 2005 1:53 PM

Jeffrey Palermo said:

Yes, Java has been around a lot longer, but not all of these tools existed before .Net debuted. For instance, fit came into being late in 2002, and the FitNesse wiki came along in March of 2003: http://web.archive.org/web/20030319020455/http://www.fitnesse.org/

Also, these frameworks aren't really that big when you dig into them, but they satisfy a niche perfectly.

One thing that is common to all these tools is that they are tremendously useful, but they don't come with the pretty MS wizard GUI. With MS tools, everything comes with a wizard, and while CC.Net has a nice interface, it still requires reading a bit of documentation.

I love the .Net runtime, and I don't take advantage of most of the MS tool features which are wrappers around the runtime which actually restrict functionality to make it easier to use: For instance, you can't nest an ASP.NET page in another ASP.NET page. This is an IDE restriction, not a runtime restriction. Use the runtime, and it works just fine (Page is derived from Control).

It's definitly a difference in culture which is largely influenced by Microsoft press releases. Morts can and do use MS tools to build software that sometimes works (well enough for some people). The non-morts (developers) can also use .Net because the platform offers the power for robust applications.

I think it's only a matter of time before some really innovative .Net projects find an audience (Jeremy's StructureMap and my EZWeb project are good examples).

# September 6, 2005 2:13 PM

Marc Brooks said:

I can tell you that at least in the O/RM world there are many tools that Java didn't spawn. WilsonORMapper is an ideal case in point... it was spawned by a _specification_ that was released by Microsoft for the ObjectSpaces O/RM that has yet to be released. I know it's not "Open Source" since you have to pay a measly $50 for the source, but still...

# September 6, 2005 5:41 PM

Jeremy D. Miller said:

Good point Marc. I'd forgotten about the WilsonORMapper. I think we're covered pretty well on OR tools, but I still think we'd be further along if ObjectSpaces hadn't been promised

# September 6, 2005 9:35 PM

hammett said:

For the records: Castle MicroKernel was not inspired on PicoContainer, please! It was the result of my experiences at Apache Avalon, from the simplicity of Fortress to the major complexity of Merlin (now Metro).

# September 9, 2005 1:13 PM

hammett said:

"I get that Linux is a real threat to MS, but NUnit and NAnt were not."

Btw during my interview process for Microsoft I stated this clearly. The answer was: we have to be coherent about open source and send just a single message, we can't say that for some cases it's alright.

I think that makes sense. And besides that, integration witi NUnit and NAnt (although makes sense) would be an implicit endorsment that they don't wanna do.

# September 9, 2005 1:21 PM

Jeremy D. Miller said:

Sorry about the inaccuracy with Castle. I know MS could never endorse NUnit/Nant and the others, but it could have made our lives easier if they had.

# September 9, 2005 2:14 PM

Jeremy D. Miller -- The Shade Tree Developer said:

Just to prove that the ALT.NET conference was 99% positive, I was definitely on an endorphin high when

# October 11, 2007 9:23 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#.

This Blog

Home
Contact

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

Jeremy D. Miller -- The Shade Tree Developer

I'm getting sick of using "hand me down" tools that are ported from Java to .Net

Comments

Second class tool said:

Jon Galloway said:

Jeffrey Palermo said:

Marc Brooks said:

Jeremy D. Miller said:

hammett said:

hammett said:

Jeremy D. Miller said:

Jeremy D. Miller -- The Shade Tree Developer said:

Leave a Comment

About Jeremy D. Miller

This Blog

Syndication

Recent Posts

Tags

News

Blogs I Read

Archives