For the most part I try for original content ….. but then I found this and I couldn’t have said it better – actually, I didn’t say it at all, and I am envious

http://www.wolfgilbert.com/Main/Blog/Entries/2008/4/17_SOA_as_the_Uber-Container.html

I’m learning about Entity Framework (the Beta 3 drop) by implementing an app to manage my collection of DVDs –  in general I like Entity Framework and will continue to use it, but every once in a while, there’s something that makes me go ‘huh???!!!’  Here’s one such case.

Each DVD record can have multiple attribute records associated with it, which allows me to attach attributes to DVDs without having to have these attributes part of the base DVD tuple definition.  This is primarily because many attributes, such as whether a DVD is a remake of another version of the movie don’t apply to all movies (I’ve thought of plotting the remake occurrance curve, i.e. I think that the decrease in risk tolerance/imagination is causing the remake frequency to rise, but thats another story)

So when I show information about a DVD, I have a few display fields that are connected to attributes, which may or may not be present.  For example, I don’t associate tag lines with every movie, but if there’s one I think is a particular mot juste for a movie on IMDB, I’ll add it as an attribute.  When the display populates some of the fixed fields that show attributes, it has to run a query that tells it if the specific attribute of interest is associated with the DVD that is being shown.  This is primarily accomplished through a member function string GetTextAttribute(DVD theDVD, string theAttributeName), that will either return null (no attribute) or a string (the value of the attribute).

Within this function I use the IQueryable<T> mechanism, as shown in the following code fragment

DVDTextAttribute ta;

ObjectQuery<DVDTextAttribute> attributes = _context.DVDTextAttribute;

IQueryable<DVDTextAttribute> attrQuery = from attribute in theDVD.DVDTextAttribute.CreateSourceQuery()

where attribute.AttributeName == keywordAttr

select attribute;

foreach(DVDTextAttribute attr in attrQuery)

blah blah blah

Unfortunately, this won’t work.  When the foreach triggers the attempt to fetch the enumerator by calling GetEnumerator on attrQuery, this is what you’ll get…

Unable to create a constant value of type 'Closure type'. Only primitive types (for instance Int32, String and Guid) are supported in this context.

Now, if you modify the code slightly and do this

DVDTextAttribute ta;

ObjectQuery<DVDTextAttribute> attributes = _context.DVDTextAttribute;

IQueryable<DVDTextAttribute> attrQuery = from attribute in theDVD.DVDTextAttribute.CreateSourceQuery()

where attribute.AttributeName.ID == keywordAttr.ID

select attribute;

foreach(DVDTextAttribute attr in attrQuery)

The ID property is the primary key for the conceptual entity, so now Entity Framework is happy, I’m (sort of) happy, and life goes on.  If you’ve just found this post because you’ve been searching for that error, you just have to be aware of the fact that Entity Factory isn’t completely matching the behavior of basic LINQ, you can’t do object comparisons as part of the query.  Another person encountered this issue and seems to have reached the same conclusion that I have, their post is here.

Moving on to my gripe, it’s based on the fact that the Entity framework is knowledgably picky about the relational model of your database, and it’s pretty good about making sure that first, you actually have a decent relational model, and second, that you don’t undertake any action that would mess up this model, and it leverages the core LINQ architecture to accomplish its good works.

SO WHY IN THE NAME OF ALL THIS GOODNESS can’t they use what they already OBVIOUSLY KNOW and let you do object comparisons when you’re comparing apples to apples?  It has enough information to know that the types being compared are identical, and it knows the primary key of the type.  The basic LINQ architecture supports this, examples of it are scattered through the MSDN documentation, and that makes this behavior non-orthogonal at the very least!

Don’t get me wrong.  Use the Entity Framework.  It’s great.  It just needs a few more things to be ‘adjusted’ before it goes golden, and the issue here is that when possible, it should support everything that basic LINQ does.  It’s frustrating when you have a system that is capable of complaining at you about all the things you (really have) done wrong, but then it doesn’t exploit that same information to make your life easier.  After all, if I changed the primary key in the DVDTextAttribute table, this code would now silently fail.  That’s just not right…

Recently, I started having problems with the error "Items collection must be empty before using ItemsSource" popping up after I’d made a few changes to my UI.  I think I understand the root trigger, but I haven’t got time to reason through the entire cause and effect chain.  So here’s my best guess…..

In simplest terms, I have a list of widgets, and when any widget is selected, the selection handler then causes another list to get populated with the attributes of the selected widget.  There’s a twist to this however.  The list of attributes is not sourced from the selection made from the widget list, it’s sourced from a specific property of that selection.

I’ve got the widget list – I click on an item, it fires some logic, and I set the value of SelectedWidget, which is a property I fire an OnPropertyChanged for, i.e. I call the bound PropertyChangedEventHandler with “SelectedWidget”.  Specifically, I implement the INotifyPropertyChanged interface with this code;

• public void OnPropertyChanged(string name)
• {
• PropertyChangedEventHandler handler = PropertyChanged;
• if (handler != null)
• {
• handler(this, new PropertyChangedEventArgs(name));
• }
• }

Inside the selection changed handler for the Widget list,  I called OnPropertyChanged(“SelectedWidget”);

Now I’ve got another listbox in the display, and this one is databound in XAML by setting ItemsSource to

ItemsSource="{Binding Path=SelectedWidget.WidgetAttributes, ElementName=_widgetcatalog}"
      

The key element to note is that the ItemsSource is set to a property of the SelectedWidget, not to the SelectedWidget itself….  Seems that this bothers XAML – it doesn’t affect it with simple scalar controls, i.e. I have text boxes bound to SelectedWidget.Name and SelectedWidget.RevisionDate, but it seems to get upset when I do this trick with a list box.

This may also have something to do with the template that underlies the attribute display list, I’m not claiming to be exactly certain – I just know that when I made the selection event handler in the code behind clear out the item binding, then clear out the list of attributes, and then reset the item binding to the new selection, everything worked fine – if I performed the equivalent action in XAML through simple databinding, no such luck….

YMMV – take this with a grain of salt – I just posted this because I got so few hits on that error message I figured a guess was better than nothing……  It kinda bugs me because I like the fact that databound controls in the form SomePropertyINotifyOn.ThePropertyThatActuallyHasTheDataIShow is really handy, you just notify when the root property changes and everybodies happy as far as scalar data displays (textboxes, etc) are concerned – the list box didn’t seem to like this approach so much

Working offline with TFS is different than with Visual SourceSafe.  On the one hand, VSS is better integrated with Visual Studio, so its pretty easy to unlock files for editing offline, you just begin editing them.  On the other hand, VSS can often get easily confused, and will then trot off and unlock everything in your solution.  When you go to reconnect to VSS, this can be annoying if other team members have edited files that you have checked out, but not modified.

TFS in general is better at this, primarily because its built around the concept of lock-free checkouts and the existence of far more sophisticated merge tools.  But one place where TFS falls down is the actual unlocking of files in offline mode, because it seems somewhat oblivious to the fact that these files are part of a source control system.  It just sees them as locked, and that’s that.

Turns out there’s a simple way around this, at least if you’re working with VS in a tabbed document view.  If you right click on the tab where the filename is displayed, you’ll see a context menu where the first choice is to save the file – this choice appears regardless of whether or not you have made any changes to the file.  Save the file, pick ‘Overwrite’ when prompted, and you’re off to the races.

As I mentioned in my previous post, I reluctantly decided to plow my server under and start afresh with a new installation.  There were still a couple of issues that came blazing in from far out in the mindless reaches of the productization effort.  I found two of them especially enlightening.  That said, the fundamental genesis of this (expected to be a long) series of posts is that I have lost my patience with being enlighten by a steady stream of WTF moments, and I’m doing what little I can to hit back.

Windows Update and SQL Server Service Pack 2

OK, so we’ve got a virgin installation of Server 2003, we’ve downloaded all the patches, installed Standard SQL Server 2005, and upgraded Windows Update so it will get updates for all the Microsoft products on our machine.  Once upon a time these were actually products, but of course the brilliant minds in the productization groups are doing everything they can to undo this legacy.  In this particular case, after a number of upgrade downloads and reboots, I am informed that I need SQL Server SP 2.

Yup.  Knew that.  In fact, in the previous incarnation of the system I had neglected to install it as well, but when I downloaded and installed the new update functionality (OK, so its a server –  I forget about it for months, and I did have the original updater set for automatic updates) it went and got SP2 and at least in that area, everything was grand.  The key thing is this was a 3 year old server installation with a lot of cruft on it, to the degree I’d have to assume that it was at least slightly different from every other server out there.

Moving back to the present, I let the updater run, it claims all is well and good, and I move on to the installation of TFS.  Note that this is a server with a virgin installation of Server 2003 and it has nothing but Microsoft code on it.  This should pretty much be a reference platform from the Microsoft perspective.  You’ve probably already guessed what's coming next – TFS reports it can’t install because the SP2 upgrade isn’t present!  So I go back to the forums, where lots of people have this problem, and yup, I sure don’t have the right version info in whatever SQL table it was I looked in.  Maybe there was some intermediate patch or something. Maybe I’m just confused.  Back to the updater – nope, it thinks I have everything I need.  I reboot, wave the magic chicken bones, clear the Internet cache,do all those other fine things – same answer – your system is fully up to date, but the version reported from SQL is off by a couple hundred, as I recall.

OK, as you’ve probably gathered from my blog, I’m not really surprised.  Dismayed, yes.  Have a good idea of who the culprits are, yes.  So I go rooting about, find the direct download for the service pack, and jam it on my machine.  Some time passes, I reboot my machine, run the TFS install, and I am golden.  It’s up, its working, my hats off to the TFS core team.

However, to the people responsible for handling testing across the family of products here, including SharePoint, SQL Server, TFS, and the Windows Update Service, I am developing a different kind of admiration.  Everything involved in this process was yours.  No other applications of any kind were involved.  This is a pretty clear demonstration to me that you really can’t work together very well, and you can’t even test your own stuff, much less its interaction with any third party products.  This is really sad folks, I remember once upon a time where there were various off color jokes about latex gloves and unpleasant probes when it came to Microsoft testing.  I remember once upon a time I would have accepted any opportunity to avail my organization or my clients organization of this testing.  These days, I don’t think I could ever run far enough, fast enough, in the opposite direction to quell my growing unease.  The bottom line is you can’t even get interactions between key components in your own flagship products tested before it goes out the door. Stay the hell away from my stuff, I think a collection of monkeys can beat anything you do.

Having put forth all that vitriol, I should observe that I would hazard a guess this isn’t the fault of the line testing groups.  I read a bunch of their blogs, they seem like smart folks, and they sure do write about some lulus that they find.  Interestingly enough though, I see very little on issues involving multi product interactions.  So I’ll apply Occam's razor and make the simplest guess.  Because the idiots at the levels that span multiple products are incapable of doing their jobs, so the entire process breaks down when it gets to them.  As hypotheses go, I’m pretty comfortable with it, it fits all the facts I have.

VS 2008 and Business Intelligence Studio.

BI Studio is a VS2005 element that is central to creating reports using the SQL Server reporting services.  Technically you can do this without BI studio, but this is a statement roughly equivalent to saying you can write a rich AJAX based web application in vi.  And once again, the product gremlins come riding in to screw everything up.  Why ?  Because BI studio is not part of VS 2008, so if you blow away 2005 (are you starting to see just what kind of bad idea this is turning out to be), you’ve got no reasonable way of authoring reports. 

What makes this unbelievably stupid is that VS2008 is being used (correctly) as a vehicle to push TFS.  And one of the big strengths of TFS is….. wait for it…… reports.  However, if you don’t like what comes with TFS, oh whoops!  We forgot to provide the specific tool you need to create those snazzy new reports.  When you consider that TFS is specifically a system designed to be tuned for the needs of an individual organization, this reaches truly legendary pinnacles of stupidity.  I’ve seen organizations where the left hand doesn’t know what the right is doing.  But this reaches new heights.  Microsoft has two black eyes – the left eye has been blackened by the right fist – and the right eye has been blackened by the left fist.  This is unbelievably pathetic.

Concluding this small series of cathartic, and for some at Microsoft, I believe well deserved, rants, I would like to profer two new slogans for Microsoft product groups.  To all of the developers there, I deeply apologize -

Visual Studio 2008 –  The most sophisticated add-in for VS2005 you can get.

Microsoft –  What would you like us to screw up today ?

Introduction

I’ve begun the (forced) conversion to Team Foundation Server with my recent (desired) transition to VS 2008.  It’s been an interesting experience to put it mildly.  As with the great majority of my interactions with Microsoft these days, it leaves me both impressed and appalled.  Impressed with the line staff for their insightful achievements and superhuman efforts to compensate in all those areas they have been so tragically let down, and appalled with the executive and senior staff for their abysmal product delivery.  I am afraid that this will be a fairly steady refrain for a while.

The first inklings that my interest in TFS would have to become more was when I discovered that VSS 6.x is no longer present in the professional VS2008 distribution.  OK, I did see that one coming, but you certainly can’t call the vision clear.  There is VSS 2005, of which I had much to say in a prior post, but it is for all intents and purposes a stealthy product, as it stands alone in terms of overall packaging, except in the widest scope of being available on MSDN. I’ve elected to do a two step migration to TFS, a first pass where I’m just moving the current working builds of my primary systems, and a followup step where I will migrate the legacy TFS data.

The Sad Tale

So lets get down to brass tacks.  In the initial attempt to install TFS, the initial tests the installer performed were a good start, correctly pointing out that my installation of analysis services was sort of hosed, my installation of reporting services was completely hosed, and I had neglected to install the latest SQL Server service pack.  Off I went to Windows Update, then off to services configuration, and then all was OK with the world.  Or so I thought……..

The next issue was bizarre – repeated attempts to run the installation would fail at the very end, with complaints about the SharePoint site being missing.  The sharepoint administration site had installed and was available, but it did insist that there were no sites installed, and attempts to resolve this by fiddling with the administration tools may or may not have worked, as I shall attempt to explain.

But first, I have to express a certain amount of admiration for those inside of Microsoft who are working on the TFS forums.  And many other forums I might add.  They are being bombarded with a huge volume of trouble reports, in fact every issue I ran into had a large number of forum posts.  While the solutions did not all work for me, I have to commend the diligent effort. I took away a strong feeling that the core teams are doing a lot to try and support their products.  The fact that they are doing this at all worries me, in that I’d rather have them working on the future or their products, and fixes to real bugs.  This of course does assume that the present is under control, which it obviously is not, and the blame for this lies clearly with the pay grades above these hardworking developers.

I finally did manage to get past the SharePoint complaints, but was then completely defeated by various issues with the initialization of the TFS databases.  I did learn a lot about the several hundred K log file contents, and I did find a number of posts relating to the problems I encountered, but many of these posts had anecdotal observations that the poster had finally thrown up their hands and plowed under the existing server installation and started fresh.

In trying to resolve these issues, I did detect certain problems with the .Net 3.5 library installation, and I knew that a long past attempt to use TFS 2005 had left wreckage strewn about the server, so I (sadly) decided that I too would plow under my existing server installation and start fresh.

Lesson Learned #1

If you’re going to migrate to TFS, and you really don’t have much choice if you want to stick with a Microsoft solution, plan on installing everything fresh.  As I have observed, the core development and support teams are working hard to try and deal with all the problems pouring in from the field, however they are confronting an impossible task.  There’s no question that after a server has been around for a few years it’s pretty much unique in terms of the upgrade path (mine had a mixture of hot fixes, service patches, and remnants of old installations).  You can’t possibly expect an internal development group to deal with this range of issues on their own, although once again I have to give them credit for obvious efforts above and beyond what should normally be expected from them.

Personally, I like the concept of TFS and I hope as I get into using it that it meets the promise of this concept.  I’d certainly recommend it, however, I would also say that if you’ve had more than you can take at this point, there is merit in considering moving out as much of this technology as possible.  I wouldn’t do it, and I advise my various clients not too.  However, in several cases where it’s come right down to it, I also can’t say that they are wrong not.

I would contrast this rather brutally with the perceived actions by the senior folk who supposedly have a larger view, where their responsibilies span both creation and delivery, and their focus is on ‘productization’, the effective delivery of technology into the field.  More and more, I wonder if they get their orders from some cabal intent on the utter destruction of Microsoft and its partners.  The amount of effort expended in this area is paltry, and the results are obvious.  The product testing, especially with respect to installation, and there with extra emphasis on the fact that there are multiple product interactions (Server, SharePoint, SQL Server, TFS) is abysmal –  many of the issues reported on the forums SHOULD NEVER HAVE BEEN REPORTED AT ALL.  For many of you reading this, at small or mid size ISVs or in house staffs, you are probably all too aware that if you conducted yourself in a similar fashion, the best you could hope for is that your organization suffered a quick death.  Being torn limb from limb by an enraged user community is probably not out of the question either.

Bottom line –  assume that the productization effort on TFS is in large something that would embarrass a third rate organization, and certainly something that should result in extensive internal bloodshed at Microsoft.  If you have weird problems with the install, its probably pointless to work your way through them.  The odds are too high that your issues have never been officially seen by the organization.  The core teams will try and help, but its not really their role, and they most likely don’t have the resources they need.  The safest path is to simply plow the server under and start fresh.  You’ll still have various ‘interesting’ issues to deal with, a few of which I will point out in the next post, but your chance of a successful outcome is much higher.

Commentary to Microsoft readers.

Pretty much the same drill as the last post.  If you’re in a development group and there’s something I’ve got wrong, let me know and I’ll try and fix it.  If you’re part of the product team, please go find another job.  You’re extremely bad at what you do.  If you feel this tail is being pinned on you unfairly, then feel free to remove it and place it where it belongs.  But its got to go somewhere, so your respective organizations aren’t such a freaking joke.

Before launching into the gory details of my recent conversion to TFS I feel its necessary to address an issue that I consider to be completely reprehensible on Microsoft's part.  It’s not a technical issue so much as a product and market decision, and as such, lies squarely within the most disfunctional zone of the organization.  The issue involves the migration of VSS 6.x databases into TFS, or rather, the inability to do so.

Background

If you are currently using VSS 2005, I think you can safely stop reading this post now, but I make no guarantees.  I don’t know if the tool works, and I’m not spending the time to find out.  I will say that the core TFS developers seem to support it on the forums, so a certain amount of confidence seems warranted. If you’re using the older VSS 6.x, you’re about to have an extremely nasty surprise if you don’t have a MSDN membership.

When you migrate to VS2008 (which is well worth doing, don’t get me wrong) you will find that you can’t, out of the box, connect to your VSS database.  You can certainly dig through your archives and find the client for 2005, which does work with VS2008, but the writing on the wall is pretty clear.  TFS is maturing, it has a lot to offer, it is the future, and it’s pretty much about time to move there.

You’ll probably want to migrate your existing VSS databases to TFS, as if you practice good development, you’ve used source control to keep your code clean.  It isn’t stuffed full of large blocks of commented out code representing alternate solutions, all of that is done with versioning and branching in VSS.  Unfortunately, you can’t migrate this directly to TFS, because the migration tool has two nasty issues.

1 –  It only works on VSS 2005 databases

2 – It also seems to have dependencies on VS2005 code, so if you uninstall VS2005 prior to installing VS2008, you just shot yourself in the foot.

Overall productization efforts at Microsoft redefine the meaning of ‘abysmally bad execution’, so it should come as no surprise that this information is not communicated to you, instead you are left to stumble across it.  If you search through the forums, you’ll quickly determine that a number of small shops are upset, and some organizations have elected to not migrate at all, for this, and many other reasons.

Now, if you’ve got a full boat MSDN license, you can certainly go get VSS 2005 –  but there are a lot of developers who don’t have that, and there also (from forum postings) seem to be a fair number coming to VS2008 from somewhere other than VS2005.  Instead of feeling welcomed, they are met with a bait and switch. 

Here’s the catch for all of you in that boat – you can get a trial version of VS2005 which will address part of the problem, but you cannot get a trial version of VSS2005 – you’re either going to need the MSDN subscription, or you’re going to need to go buy a copy of VSS 2005, or you’re simply going to have to abandon the legacy information in your VSS database (there is an alternative I will discuss below, but its potentially even more expensive).

VSS 2005 was always a bit of a stealth product.  Not necessarily its fault, it had a very short life between 6.x and TFS.  It wasn’t ever truly integrated into the Visual Studio products, it always stood alone as a separate SKU.  So there’s a large body of developers that didn’t use it, and continued on with the legacy VSS.  TFS 2005 was simply too big an effort, and many didn’t even know about VSS 2005, because it wasn’t part of the product suites they were exposed to. However, understanding the genesis of the problem does not excuse it, in fact one would expect that the proper parties would be sensitized to the issue.

Commentary

Whatever morons made and reviewed the productization plans for TFS 2008 should have had this little datum at the forefront of their minds.  Specifically, they should have been asking, if we’re trying to move our customer base onto TFS 2008, how do we make that easy for them.  Half of it they got right, have a low cost version of TFS suitable for small shops.  I can’t say I believe they deserve credit for that, from the outside I’d be more likely to believe the TFS team themselves are responsible for that.

Some weasel is probably quite pleased with themselves, because they’ve read the situation as one where the conversion of small shops to TFS (under pressure) will result in additional revenues for VSS2005 because these shops will be compelled to get access to it one way or another. Look, little weasel, let me make something really damn clear here.  An enormous amount of the innovation on your platforms comes from these small shops, they’re usually strapped for resources of all kinds, and a large number of them may simply stay with the legacy VSS, which the posts on your forum should indicate to you, if you’ve got five working neurons left in that empty head of yours.  This then screws the larger shops, because it cuts down on the number of potential hires with TFS experience, as the small shops that fail (most of them) serve the additional purpose of generating a constant pool of available employees with experience with later Microsoft technologies.  I know one large Microsoft reference customer who has yet to migrate to 2.0 in any serious way.  They are considering 3.5, bypassing the majority of the 2.0 migration, but you’re not doing them any favors by making people with experience damn hard to find.  I’m looking forward to bringing this up to them, and I hope to be a spectator at the meeting I am reasonably certain will follow.  The pity is that I know the guys who will take the heat at that meeting, and its just going to be another case of punishing the innocent while the guilty go about their activities, oblivious to it all.

Recommendations

In short, if you’re a small shop moving to ViS2008, you’re doing the right thing.  And you can get the workgroup version of TFS which I do believe is the future and is also a good thing.  And after a year romping through all these new technologies, my hat is off to the people that created them.  I strongly recommend you consider them.

But you’re going to have to bite a bullet –  you’re either going to have to get an MSDN license version of VS2008, or you’re going to have to abandon your historical source.  And you may well look at this and say that Microsoft has gouged you for a product you need for one calendar day.  And you are quite correct.

An Alternative Strategy

A while ago I wrote some custom tools for version management that interoped with the VSS 6.x code –  I plan on looking at these to see if they can be connected to TFS to provide a migration alternative.  I plan on giving away whatever I have in source form, but I don’t plan on writing the whole thing myself.  If there’s anyone else out there that would like to participate, sing out by posting a comment.

A comment to the Microsoft readership.

As far as the Microsoft folk that are reading this – if you’re a developer and I’ve gotten something wrong – tell me, I’ll fix it and make sure the right information is available –  if you’re involved in productization, you can go straight to hell –  I have a very long list here, I’ve done everything I can to work with you clowns, and you just screw up worse and worse and worse.  I want the things your developers have done, very badly.  It seems the only way I can get them is to begin kicking the product folks in public forums. I am grateful to everything Microsoft's developers have ever done for me, and I am now completely furious about everything that Microsoft's productization teams have done to me.  You’re screwing up your own business model, and you’re screwing up the business models of a lot of people that have partnered with you. 

The googleplex is now grubbing around inside code distros and indexing them -  of course, someone immediately got the bright idea to look for comments containing profanity - and this is the result -  quite funny - Thanks JeffD!

I’ve been wrestling with an issue at work and thought I’d publish some results.  I’ve run this by a few peers, and needless to say am exercising the great irresponsilbe freedom afforded by having one’s own blog, I’m publishing the work to the wider world before my peers tell me I’m an idiot.

I was recently asked by a client to revisit the assumption we had made to build a framework from scratch, and to determine whether this was in fact the best course.  The counter proposal was to develop services independently, make/buy a set of libraries used by services to satisfy cross cutting concerns, and if a framework is truly needed, buy BizTalk or Tibco or something similar.  The argument centered on the cost of developing the framework and the benefit that framework could provide in reducing service development costs.

I wrestled with this for a while, doing various costing spreadsheets, but I kept thinking about the fact that for a company selling frameworks, this works for them and their clients – for enterprises creating their own framework, it often turns into a disaster (yes, for many reasons, but the value proposition is usually the main culprit)

I did a lot of research, and found much stuff, but no central governing principle – but I think I stumbled over one (perhaps I just rediscovered it) – without further ado, here’s how I think you can turn the decision as to whether to build or buy a framework into a more classical make/buy decision.

1 - For any SOA, you can define an average cost to develop services – it matters little whether this is the initial development cost or the entire SDLC cost, the bottom line is that you can average together all your services and say that in general, a Service (S) costs (D) dollars to develop over some interval of its lifetime

2 – The cost of developing a framework can be expressed as a percentage of the cost of developing the average service.  In buy scenarios, this is usually fractional, e.g. an average service costs the organization $10K to develop, Biztalk costs $6K, therefore the cost multiple for buying BizTalk is 60%.  Conversely, in build scenarios you could argue that the framework costs 5 times (500%) of what a service costs (where that cost is estimated without benefit of having the framework), and you can say that in general, the value of the framework is that it reduces your development costs 50% (wild numbers, I know, but it makes the math easier).  In this example, you would need to create 10 services in order to recover the cost of developing the framework.

The real meat of the argument always boils down to the same thing - how much does it cost to develop the framework, what’s the efficiency benefit of having the framework, how do we make sure this is the appropriate investment -  it seems to me, after a lot of thought, that this is in fact a mechanical exercise AFTER you’ve decided a few key points

               1 -  What is the average amount you would expect to spend developing a service given you had no framework ?

               2 -  How much will your framework cost, relative to the cost of the average service in #1

               3 -  What level of efficiency do you expect your framework to give you in terms of service development cost reductions

In discussing this, the most ardent foes of a framework will usually still grant it reduces development costs by 5-10% - the most ardent supporters will not usually move beyond it reducing costs more than 30-40% - the foes will say it costs 6-10x to develop the framework as opposed to the cost of developing the average service – the friends will say 4-8x

The justification for creating any framework is that it makes overall development cheaper than development without a framework (duh) – However, this is just a variant of a make/buy problem, which means you should be able to calculate the breakeven point, i.e. the number of services you would need to develop based on the framework in order to recover the costs of the framework.  Loaded development costs, the period of the SDLC covered, etc, are all red herrings – the real deal is just how much does it cost relative to unoptimized service development and how efficient does it make you – that tells you how many services you need to develop in order to recover your costs. 

The latest version of IE (7) defies description –  I’d love to say that it runs like a pig, but that would imply that it runs more often than it does, and in general would be an insult to pigs everywhere.

Its not like the developers at MSFT are stupid, they’ve done some truly brilliant work over the last few years.  And it’s not like I haven’t read all the stupid posts about disabling all of the various phishing philters and the like.  But the bottom line is that on every machine I run IE on, I need to have the task manager handy, in order to kill it when it locks up for the umpteenth time.

I ostensibly make my living focusing on Microsoft stuff, so I used to stand on the sidelines and watch when many others I knew began to use Firefox as their primary browser.  And my reward for this ?   In order to get any work done I now have to use Firefox, and I only use IE to access sites that are problematic with firefox, namely some microsoft.com pages….

What kind of utter cluelessness is running rampant in Redmond these days –  they have done some truly seminal work with the new core technologies (W*F), yet the organization as a whole is a disaster zone.  I’m now finding that when asked for advice on developing a new site, I can respond positively about some msft stuff – but I am forced to add a caveat –  don’t use IE during development, and make sure you select a non-microsoft tool for page design.  The entire advantage to any specialization on Microsoft is being destroyed, by Microsoft themselves.  A friend of mine (an admitted Mac fan, err zealot) argues that in twenty years Microsoft will be completely irrelevant –  I wonder if he may be right.

The real issue though ?  – If you can’t keep it together with your flagship products, isn’t it best to assume that any new initiative you have is probably going to spiral into madness ?  But that’s a separate post on Vista for a later time.  :-)

On Saturday, December 01, 2007 Dan Scherlis and I gave a talk about how game companies work at the Microsoft GameDev day at Harvard.  We both had a lot of fun giving this talk, and equally enjoyed the presentation from the folks at Second Life and Mike Cummings presentation of the basics of XNA programming.  I hope that the attendees liked this talk, and that there is more to come.

I’ve posted my slides for the talk here.