The pragmatic .NET developer

31 January 2008 .NET ALT.NET

Long-time friend, fellow co-host of the GSDF and the coding genius behind the open-source Ogre3D engine Steve Streeting has written an interesting piece on Open source adoption; countering the fear and doubt. I have no doubt that this was fueled by a lengthy discussion last night in the Ship & Crown pub – a common ritual after our GSDF meetings.

The reasons why I adopted .NET as my primary platform despite being tied to a single-supplier are:

Ease of deployment & set-up
Low resistance to adoption
Great tool integration
Official & community support
Love for C# and the CLR

The ALT.NET movement

Many .NET developers are reluctant to look wider afield but this is not exclusively the case and a person focused on the .NET platform but open to selecting beneficial alternatives to the Microsoft prescription is exactly what the Alt.NET moniker was coined to encapsulate.

SourceForge lists over 6,000 open-source C# projects alone and many well-known open source Java & PHP projects have made their way to the .NET platform. NHibernate, NUnit, NCover, Spring.NET & DotNetNuke alongside new .NET developments such as xUnit.NET, SubSonic, Subtext etc.

Best of breed

Where a non-Microsoft option is functionally superior or more cost effective I will consider it whether it is proprietary or open source.

I do not however select a solution simply because it is considered the “best of breed” at that particular moment. Integration, training, availability of support and experienced developers, deployment, cost, barriers to entry and road-maps must be taken into account.

Given that Microsoft provide the .NET platform anything ‘in-the-box’ scores highly in many of these areas.

Sometimes a non-Microsoft solution comes out on top or there is a compelling reason to adopt it anyway. This is why my toolkit already contains Subversion, TortoiseSVN, AnkhSVN, Reflector and NUnit.

It’s also why I currently run Mac OS X alongside Vista, use WordPress as my blogging platform, prepare my presentations with KeyNote and use OmniFocus to organize my life.

Robust alternative projects

I have concerns about longevity and support on projects from companies and hobbyists regardless of whether they are open source or proprietary.

NDoc, CVS & NullableTypes are three I’ve used which died when an alternative commercial or open source project gained more momentum and SourceForge is seemingly littered with thousands of dead projects.

If a project you rely upon dies you have one of a number of options:

Migrate to something new (gained little from open source)
Fix bugs and problems yourself (time spent working outside your business domain)
Have a support contract with somebody else to work on it (single-supplier scenario?)

Competition is important

Competition is important but I can not, in a professional capacity, recommend to customers something that I believe is less suitable in the interest of keeping the competition healthy.

Confusion about choice

I hit this one first hand developing my final-year degree project which required development of a web site in Java.

The number of choices for Java was incredibly confusing despite knowing the syntax. J2SE or J2EE? JSP, Struts, Spring or another servlet package? What about the database and ORM? Application server? What versions work together? What overlaps? Would I be able to get experienced developers? If not how long to train them up?

.NET has many options too but I can start with the .NET Framework and get right into solving the domain problem. If the going gets tough I may have taken a wrong turn and need a different solution. That could involve choosing an alternative component or framework but now I’ll know what problem I’m trying to solve when I go looking.

Developers on complex projects felt that WebForms wasn’t ideal – it is hard to maintain, the output bloated with leaky implementation (ViewState) but it serves many developers well enough.

Open-source projects such as MonoRail addressed this taking cues from Ruby on Rails. Microsoft acknowledge this and add a similar MVC framework going so far as to support additional engines and components allowing elements of MonoRail to be used. Those guys could drop the glue required to get their engines into the pipeline and just concentrate on engines if they wish.

What works for me

Stay small and focused until you feel friction.

Friction isn’t always technical or immediately obvious. It might be future plans and it’s often people. It might be what isn’t there and will never be.

Time lost on friction is not spent developing your domains features.

If another solution causes less friction, use it but don’t underestimate unknowns.

I guess that’s just being pragmatic.

[)amien

10 responses

A few comments...

What makes you think CVS is dead? It's just stable, and needs few updates anymore. Sure, SVN is the current darling (I use it for new projects too) but that doesn't for a second that existing CVS repositories aren't perfectly happy the way they are. This is something I have a major problem with - people thinking that 'no longer fashionable' means 'dead'. If we go by that rule, .Net is dead and Ruby is king (in a couple of years it'll be something else). It might be the case in the proprietary world because suppliers deliberately EOL their products to sell you a new one, but popular open source projects don't die - ever. Unfortunately you don't have a lot of choice in the .Net community so perhaps you've ended up backing projects that didn't have much serious long-term support. Fashion is fickle, what matters for investment in real systems is stability and maturity. Mature systems might be boring, but they work and are here to stay.

"Competition is important but I can not, in a professional capacity, recommend to customers something that I believe is less suitable in the interest of keeping the competition healthy."

You've got that entirely backwards. It's not a case of 'keeping competition healthy' at all - competition is always in the customer's interest, it's basic economics. You may have never experienced the detrimental aspects of a lack of competition, but that doesn't mean they don't exist.

"Have a support contract with somebody else to work on it (single-supplier scenario?)"

Paying for support isn't a single-supplier scenario, it's just a safety net. You don't need it, you're not forced to take it, and it has no bearing on your use, development or deployment of the product. Single-supplier issues are about a lack of consumer control; taking out an optional supplementary service doesn't affect the underlying dynamics of who controls what.
steve – 31 January 2008
Oh, and about training / confusion - it's all about familiarity really. You've been very Microsoft oriented for years, so of course anything else (that isn't trivial) is going to be a rougher ride. To a total newcomer, .Net looks similar to how Java looks to you probably - should you use WebForms, what kind of data access is best, should I use VB.Net or C#, should I aimat .Net 2.0, 3.0 or 3.5, yadda yadda. Having trained many developers in Java and other environments I wouldn't say any of them is harder than the other, but looking across to a new environment is always daunting.
steve – 31 January 2008
Finally, as I tried to make clear in the article, I'm not trying to say that I think you're wrong in choosing .Net - as you say, what works for you is inherently 'right'. I can especially appreciate that in the local environment where there's not many IT people to choose from, and firms mostly have a small IT function which has most likely evolved from small office programs - so Microsoft is a more natural choice. My background of course comes from the other end - an organisation that was running custom-built mainframe software since 1983 and for whom off-the-shelf stuff just wasn't an option; software development is a major investment. I inherently moved in circles (UK / European software developers mainly) who didn't use Microsoft all the time, in fact it wasn't even considered close to mature enough - these are teams that had worked on things like the billing systems for all the trains in the UK for example. We just come from very different backgrounds which have shaped our preferences. I guess it would be dull if we agreed on everything ;)
steve – 31 January 2008
Coming to .NET is a lot simpler than coming to Java although admittedly some of because it has less legacy cruft accumulation.

There tends to be one obvious way to do things based on what is provided in the .NET box. If you want to write web apps WebForms is where you start. Where you start with Java is anyone's guess.

A project not being actively developed is as good as dead unless your project isn't moving either.

You yourself have had first hand experience of this with the graphic file format decoding mechanism you used in Ogre3D. You wanted to support Mac OS X and newer formats and Devil wasn't moving so you switched to FreeImage. The fact the source was open might have been fine for a bug fix or two but you certainly didn't want to start maintaining image loading code or you'd have not used a library in the first place.
Damien Guard – 31 January 2008
"A project not being actively developed is as good as dead unless your project isn't moving either."

True in some cases, but very untrue in others. By 'actively developed' perhaps you mean 'adding more features'. There are a ton of cases I can cite where adding new features is just disruptive - if a solution does what you need, and it's getting bugfixes, that's enough. Stable systems are stable because they don't change that much. When I'm developing on top of libraries, I actually prefer if they're not changing much, beyond routine maintenance, because changes underneath me are a distraction. Of course that only works if the solution is mature enough in the first place - and I personally find that Java frameworks are more mature, so don't change anywhere near as much as .Net does. Personally I view that volatility as a lack of maturity rather than an attribute to be lauded.

Re Devil: it had bugs that weren't getting fixed, that's why we switched - it had nothing to do with wanting an actively changing feature list. Had DevIL been fixing bugs more often it would have been less of an issue, because feature wise it was fine.
steve – 31 January 2008
"There tends to be one obvious way to do things based on what is provided in the .NET box. If you want to write web apps WebForms is where you start."

This actually illustrates my reasons for preferring choice. The 'one solution' set up is easier to grasp, but WebForms haven't exactly set the world on fire. If the one option you're offered isn't very good, that's not a great position to be in. In an open source world, there might have been 5-10 projects targetting this, and the rubbish ones would just fall by the wayside, leaving a small number of good options. Which one you like best is down to precisely what kind of application you're making and perhaps personal preference.
steve – 31 January 2008
"In an open source world, there might have been 5-10 projects targetting this, and the rubbish ones would just fall by the wayside, leaving a small number of good options."

Open source solutions don't suddenly die but experience a kind of half-life radioactive decay if I understand your other response. They stick around on sites like SourceForge getting little or no attention - is it because it they are mature or abandoned?

Coming to Java for the first time wanting to write a web app is a daunting experience. You'll need some guidance and whoever gives it will be recommending either what they are invested in or what they think is the latest and greatest unproven technology depending on their persona.

Even 5 solutions to a single problem is too much when you are starting out. It has been described as The Tyranny of Too Much Choice and piecing together software is worse given you must choose a solution before you understand the problem. You could spend months selecting components, tools and framework before starting to deliver real end-user requirements which may, and often do, take you in a different direction to the one you thought you were going in.

Give me a single set of tools to start and when I outgrow one I'll have a clear idea of what I want to replace it.
Damien Guard – 31 January 2008
A project that's not getting many updates anymore but does what it says on the tin is often a perfectly good choice. The user population is usually the best thing to go by - successful projects probably have a 1:10000 or more ratio between contributors and users. If a few books have been written about them, esepcially if they're getting into their second editions or later, that's also a good sign. Maturity isn't that hard to judge, you just have to look beyond release frequency - it's perfectly normal for there to be several very healthy projects in the same area.

"You'll need some guidance and whoever gives it will be recommending either what they are invested in or what they think is the latest and greatest unproven technology depending on their persona."

How is that any different to .Net? Some people will recommend VB.Net, some will prefer C#, some (like you) will push the bleeding edge features like LINQ, others will stick with older tech.

"Even 5 solutions to a single problem is too much when you are starting out. It has been described as The Tyranny of Too Much Choice and piecing together software..."

That might apply to juniors, but as experienced engineers / consultants it's our job to make sure we know the landscape a little better than most and to be able to make these kinds of choices. There is no universal 'best' answer of course, but the reason people pay us is so that we can make informed decisions about the best approach for the particular problem at hand. It's not like we have to do it in a vaccuum, there are a ton of books and articles discussing the relative pros and cons of different set ups. Probably none are entirely objective of course because everyone has their favourite, but as professionals we're supposed to be able to sift through all that to make as balanced a recommendation as we're able to. We should be able to leave the language/platform loyalty to the junior programmers and make a rational judgement, although of course we each have our own leanings.
steve – 31 January 2008
With the sheer number of combinations of new and exciting things out there following and evaluating them all is a full time job - with or without other people's opinions.

At the end of the day I need to deliver functionality because that's what they're paying for.

The search for the holy grail combination of frameworks and architecture isn't what they ordered.
Damien Guard – 31 January 2008
It's true, but I do think that it's possible to concentrate too much on purely ground-zero implementation and not enough on direction & strategy. As much as we all need to get our heads down and implement, it is a good idea to poke our heads up once in a while and check our direction - that's one of the benefits of things like the GSDF I think.

In an ideal setup it's the job of programmers to do most of the coal-face delivery of code, analysts to figure out what business features are needed, designers to make sure the implementation is good, and architects to focus on technical direction. In smaller projects / teams it's of course common for one person to be doing all of these roles, which means it's very hard to get as much focus and inevitably, results win and things like analysis & strategy tend to get glossed over, in my experience. As you say, it can easily be a full-time job to keep on top of everything - which is precisely why the good architects (the real ones, not the ones who just like to use the title) spend most of their time doing exactly this. We used to have access to these kinds of people and it was really very useful - they'd not only do their own small-scale tests but they had access to tens of real-sized projects in the last 12 months, each feeding back practical experiences from their design / senior programming teams on what worked well, what could be done better. It's not easy to get hold of the good ones, because they're in demand, but I learned a lot from the time I spent with them.

I accept that most of this is idealistic in Guernsey where you're lucky if your team is bigger than you can count on one hand. One of teams I worked in was considered small by the standards of the people I was working with, but it had 2-4 analysts, 2-3 designers, an architect (part time, needed less as time went on), 12 programmers, 5 system testers, and a couple of managers. I operated mostly in the designer and programmer roles, and ended up being a local manager and occasional architect. I tried to learn as much as I could from the others while I had the opportunity. 'Large' teams have their own problems of course, not least communication, organisation and agility to change, but once you've experienced that kind of full-cycle process it's hard not to want to at least pull the best aspects of it into your normal working practice, and one of those is really trying to keep an open mind about what's out there. It's why I'll happily listen to .Net presentations even though I doubt I'll use it in the near future, given my particular needs, and why I enjoy debating issues like this. It's all good, experience-building stuff and I'm sure it'll all come in handy some day.
steve – 1 February 2008
Avatar (Required)

Name/alias (Required, displayed)

Website (Optional, displayed)