hide all comments


Reinventing the wheel - naughty in science, daft in business

October 23, 2006 21:01:59 +0300 (EEST)

More frustrating than seeing research being duplicated is to see companies wasting huge amounts of resources on using the prototype and first version tools from Microsoft and Eclipse. I really don't get that: at least while they're learning about DSM for the first time, surely it's better to learn with a decent, stable tool, that removes all the low-level details?

It's like my wife, who just learned to drive. at the driving school she had a nice modern car to learn on, with automatic this and power-assisted that. Only after she had learned how to drive in general with that, was it sensible for her to move on to the more 'interesting' challenges presented by our 1987 VW Passat. Starting out with the Passat would have been a nightmare.

I understand perfectly that a company would want to save money -- after all, I bought the Passat for 450 euros, even though a better car wouldn't have broken the bank -- but I just can't see the savings when you take time into account. One company at the DSM workshop had been working with a team of four for 36 man months, just to get the first version of a DSM solution with Microsoft's tools. They expect to have to commit two people full time to maintaining the solution. Even among the largest MetaEdit+ customers, there isn't a single person who has to be devoted full time to maintaining the modeling tool. If you remember how precious a resource top expert developers are (and how much you have to pay them!), is it really sensible to be wasting these people's time on fighting bugs and reinventing the DSM tool support wheel? That's what the team above has had to do, since MS DSL tools have no support for linking information over several models -- something MetaEdit+ has had out of the box since day 1.

There -- now I'm moaning too! But I do think it's a different issue from the point of view of the student and the company. The student probably hardly loses out at all: most professors sadly won't notice, unless it happens to be their particular area, and so at least up to Master's level they can probably get away with it. Companies however are paying the cost every day. I have no problem if they decide that another tool is better for them, but they should at least do a proper investigation of what tools are available.

Our market research shows over 50% of expert developers in organizations building software for products know MetaCase's MetaEdit+ -- more than for Microsoft's and Eclipse's tools -- and a lot are working with it or looking at it, which is great. Given that the message has reached its target customers that well, what's the explanation of those who say they haven't heard, or have heard but not looked? If they're not interested in DSM (yet), that's fine -- but if they're serious enough that they're spending man-years on DSM, they might want to spend 1% of that time to save themselves 90% of it!


Adapting MetaEdit+ vs. alternatives (Eclipse, etc)

[Michael Urban] January 19, 2007 17:22:06 +0200 (EET)

You seem puzzled that developers are interested in M$ and Eclipse solutions.  The answer is simple;  price!  You can justify the productivity increases all you want,  it won't produce an increase in your user base.  I suspect that your product is "price elastic", and a reduction would increase your user base.  Based on my experience, your price is above the "critical point" where wide adoption would take place.  I don't know the exact price point, but your current offering price is definitely higher.

I hope this feedback can be useful in your future planning.  It would be a great step forward if more developers could use your tools to increase productivity.

Price is only one factor - but how does 150 EUR sound?

[Steven Kelly] January 23, 2007 11:52:56 +0200 (EET)

Thanks for the feedback, Michael! I'm not puzzled that people are looking at the Microsoft and Eclipse DSM offerings - even though half of the target market knows about MetaEdit+, that still leaves half who will hear about DSM first as an add-on to their IDE. What surprises me is when people decide to start projects of several man-months or years with one of those frameworks, without doing the due diligence of finding out about alternatives. I suppose it's a common enough mistake in many areas, but in metamodeling it seems particularly rife. In what other area could somebody write a PhD on a set of tools without ever trying a single one of them?!

As you've probably noticed from my blog entry posted the day before your comment, we're making MetaEdit+ Workbench available for 150 EUR. Our main aim is to make sure nobody has to leave it out of a trial of the available tools because of price. When people have tried the tools, they can make up their minds about which they want to use, and which is the most resource-efficient choice overall. 

I'd love it if we could simply drop our prices and end up with more people benefitting, without going bankrupt in the process. For that to work, there would have to be a large number of people ready to use DSM seriously. That day is coming, but to be honest I don't think it's today. Many are interested in the idea, maybe even in playing with the technology, but only a small percentage of those are actually using it for real industrial projects. This is particularly true for the MS and Eclipse tools, which as they stand are not ready for industrial use. Their adoption is at the "innovators" stage of the technology adoption life-cycle, whereas most people using MetaEdit+ are from the "Early Adopters" stage and the leading edge of the "Early Majority".

A recent independent survey of lead developers in Europe asked what price they would pay for a DSM tool. The answers were between 5 000 and 10 000 EUR per user. The serious UML tools have tended to be around this price, and the new UML-based MDA tools are even more. DSM offers far more productivity than those tools, at a price point that managers are used to paying. Still, pricing is always a conversation between vendor and market, and on a smaller scale between a vendor and each customer. More interesting than the price paid for a tool is how much it costs you to use it to build your own modeling language, how much it saves you when it is in use, and how much it costs you to maintain. But I'll freely admit that when it comes to buying things for myself, I often make the mistake of focusing just on the initial price tag!