ToDotNet

Convert.ToDotNet(InstanceOfWorld)

  Home :: Contact :: Syndication  :: Login
  172 Posts :: 0 Stories :: 175 Comments :: 22 Trackbacks

News





My Vista Score...
3.4




Archives

Post Categories

Image Galleries

Affiliations

Blogs I Read

Interesting Links

My Links

Alex points out that ObjectSpaces, a technology for object-relational mappings, will be released when Longhorn comes out. Initially, it was supposed to be released together with Visual Studio 2005.

The delay of ObjectSpaces itself is not something that touches me personally, although I am gaining interest in O/R mappers since most of my development projects involve moving around data in databases. And I would have preferred a technoloy that is being backed up by a company that can support it for more than one or two years. Also keeping in mind that you would imagine that a team of clever architects and developers are behind the product.

What bothers me, is that ObjectSpaces, together with Yukon, Whidbey, and all 'good stuff to come' will not be available within the planning scope of any of the projects that I am working on or will be working on in the near future. Even though there is so much information flowing out of Microsoft on these products. As Dino Esposito puts it “ObjectSpaces is one of the most interesting new features in Microsoft Visual Studio code-named "Whidbey". ” And this was three months ago. I very much wonder about the planning process at Microsoft...  

So on the one hand you've got Microsoft and affiliated authors promoting the newest of technologies with daily changes to the release schedule. On the other hand there seems to be a growing number of developers crying out to focus on todays issues. Let's not mention the May 2004 issue of MSDN Magazine shall we? 

This is an old debate I'm sure. Even though I'm a developer right now, I have a degree in international marketing (and public administration, but that's another story) and one of the first principles you learn as a marketeer is that quality is very much dependent on how you manage expectations. If you hype your product too much, you're likely to get a negative response when you finally deliver (if at all). So you're bound to get negative feedback when you fail to manage these expectations properly. Microsoft has, however, always had a clever technique where they would introduce something new and deliver it within a timeframe that was only just within reasonable expectations, although always delayed from its initial schedule. I fear that this time, they're threading a very thin line.

 

posted on Saturday, May 22, 2004 11:29 AM



Feedback

# re: ObjectSpaces not until Longhorn 5/22/2004 12:23 PM Frans Bouma
"And I would have preferred a technoloy that is being backed up by a company that can support it for more than one or two years. "
How do you define support, if I may ask? People who have build their Oracle ASP.NET applications around .NET 1.1's Oracle provider for example are still waiting for simple bugfixes for the bugs in that provider. Just an example. (or the winforms bug I reported 1 month ago. I'm still waiting)

Looking at the focus-change of Microsoft regarding Objectspaces, I can only conclude that IF you want an O/R mapping technique AND support, you'd better go somewhere else than to go / wait for Objectspaces.

I agree with you on the rest of your blog btw. I'm not bothered by the drop of Objectspaces but I am worried about the project-focus changes we've seen lately. This isn't the first time: several people close to the Yukon development process have said the main focus of the project was changed several times. That can't be good.

# re: ObjectSpaces not until Longhorn 5/22/2004 1:50 PM Christian Hassa
I totally have to agree with Frans.

I wonder how many people which have started investing in ObjectSpaces assuming it will come with Whidbey feel now like beeing left out in the rain in comparison to others who are using products from smaller vendors (and receiving good support from them).

# re: ObjectSpaces not until Longhorn 5/22/2004 2:05 PM Sander
Frans,
support is bugfixes, among other things. But it's also new versions every once in a while, e.g. like ADO 2.x. Remember WordPerfect? In version 7 they had their own mail client, in version 8 it was replaced with Netscape software (if I remember correctly) with no upgrade path whatsoever. Perhaps that's what I consider important. If you upgrade from an old version to a new one, there has to be an easy way to upgrade. To me, that shows that serious thought went in to the initial product. Question (I honestly don't know): is there an easy upgrade path from LLBLGen v1.21 to LLBLGen Pro?

But sure, if a serious bug is found, you need a serious response.

# re: ObjectSpaces not until Longhorn 5/22/2004 2:34 PM Frans Bouma
I agree, existing customers have to be given value for their investment and offers so they can keep their investment valid and don't run the risk of serious money loss just because a tool is no longer supported.

It IMHO comes down to how big their investment is. If a user buys a license for tool T v1.0 I then assume T's featureset was rich enough for the user to buy a license. If T is very expensive or very influencing (an O/R mapper is influencing your code: you can't swap to another O/R mapper easily no matter what the vendor tells you) the user has to be given the confidence that the invested money and time and commitment is not a big risk for the user, for example by supplying upgrades for free, including a lot of customization features, offer sourcecode to the users etc. However, T's featureset did appeal to the user, it did work for the user. Just because the company releases T++ doesn't mean T stops working :)

LLBLGen Pro is build from the ground up, however you can migrate existing apps to LLBLGen Pro as it supports a feature which lets you call stored procedures with easy methods and f.e. get results easily. This means that you can simply create a new project, add the procs you generated with the old version and call these instead of using hte old classes. You can also use them side by side this way and migrate your application over to entities when you feel like it. Due to the template system, you can still write a template set which generates LLBLGen 1.21 code btw. :)

It's not optimal, but that was also never the intention. Upgrading is never optimal. Upgrading shouldn't be seen as a necessity either. Like using O/R mapping just because it's 'hot' when you have a complete app using stored procs and datasets :)

BUt what I was trying to say was: even though MS is behind it, it doesn't make the tool being better supported. I mean: ASP.NET 2.0 will be a complete rewrite of ASP.NET 1.x. Migrating from ASP 3.0 to ASP.NET is not that great (you can't share session objects among them, which is a bummer). Not weird, ASP.NET is completely different, but it shows how techniques sometimes have a short lifetime, also with big companies.

Post Feedback

Title:
Name:
Url:
Comments: 
Protected by Clearscreen.SharpHIPEnter the code you see: