Andrew Peters’ Blog

This seems to have gone under the radar a little bit, what with all the recent Microsoft DLR/IronRuby news, but the QUT guys released 0.7 of their Ruby .NET compiler this month too - and it sounds like they are making good progress!

Since the last release we have added support for debugging (by generating pdb files) and have created a Visual Studio integration package allowing users to edit, build, execute and debug Ruby programs within Visual Studio 2005. This includes syntax colouring, error highlighting, brace matching, hidden regions, Ruby.NET projects, project properties, project templates and project item templates. Ruby.NET projects (.rbproj) enable multiple Ruby source files to be compiled into a single .NET assembly.

I wonder where we will see Rails.NET running first? :-)

Yesterday, we were excited to announce the formation of a partnership with Castle Stronghold, a best-of-breed .NET development shop and some of the fat-brains behind the Castle Project.

This is really exciting for us as we now have direct access to some of the best .NET talent in the world, including the likes of Castle project leader Hammett (Hamilton Verissimo).

For any New Zealand organisations considering undertaking a .NET web application, I strongly recommend talking to us. I believe you would be hard pressed to find a development partner who can deliver with the speed, quality and low-cost of Mindscape/Castle.

Ambler nicely articulates in The consequences of fixed-price IT projects the fundamental problem facing IT services companies.

Basically, the problem boils down to an impedance mismatch between the traditional customer/vendor dance on the one hand and modern software development methods (agile) on the other.

My feeling is that IT services shops should use variable-priced contracts as a competitive advantage! Why? Because as Ambler points out, more often than not, fixed price projects are a mess. I’ve seen this first-hand and it seems particularly endemic in the New Zealand market. Such projects lead to, among other things:

• Angry/disappointed/frustrated customers as the price goes up late in the delivery, or when the delivered system sucks.
• Low staff moral as they are left to pick up the pieces (read long hours.)
• Developer frustration as attempts to bring in agile methods are mostly futile when working in a fixed-price setup.
• Propagation of the fixed-price vicious cycle. The customer was burnt last time so this time the contract will need to be even more bullet-proof.
• Increased risk for all stake-holders! The vendor has no idea what they are building or how much it will really cost - even though they have committed to both in a contract! The customer has signed up to get a system that may not meet their requirements and will most likely cost more than they expect. When these cost overruns come near the end of delivery, they are virtually impossible to walk away from. Some despicable vendors actually leverage this approach to make more money. i.e “That sounds like a change request and it sounds expensive.”

So what would I do if I were running a services company?

Embrace contracts based on “variable-priced projects with gated investment based on interim deliverables (ideally working software.)” Sure, some customers will require education and some deals will just have to be walked away from. But over time, constantly delivering better software, more quickly and with less risk is just too compelling and word gets around. I have no doubt that the first service shops that can successfully adopt this strategy will win.

We at Mindscape are looking for beta testers to help us iron the wrinkles in our latest product. More info on our site.