Thursday, August 10, 2006
Yesterday I recorded two more DNR TV shows on CSLA .NET with Carl Franklin, so watch for those to go online in the next few weeks. Carl does a nice job of editing the recordings and cleaning up the audio, so it takes some time between recording and "airing", but it is well worth it!

Thursday, August 10, 2006 1:57:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Saturday, August 05, 2006

People often ask me how business is going, or how Magenic is doing. I answer “good”. But that’s not really true.

 

It turns out that it is better than good. I’ve been in consulting, one way or another, for nearly 12 years now and there are a couple times of year when things always slow down: late summer and the end-of-year holidays.

 

Well this summer, for the first time in my recollection, summer has gotten more busy, not less!

 

So I’m posting this blog entry in an attempt to address Magenic’s primary issue right now: finding good .NET development resources. Yup, we just can’t find enough people with good .NET experience. This includes regular Web and Windows .NET development, middle-tier work and SQL Server. But it also includes Biztalk Server and SharePoint Server as well. Any peripheral technologies like content management are always welcome too.

 

I’ve been with Magenic for 6 years as of this month, and I’ve never regretted my choice to work for the company. Greg and Paul (the owners) have steered the company through the dot-com bubble and its subsequent crash with admirable skill. And while no one could say 2002-4 were fun, I can honestly say that I felt more secure at Magenic than my friends at other companies were feeling at the time.

 

Sure, consulting is consulting. If you want to come work for Magenic you need to realize right up front the realities of being a consultant. But given that, I find it hard to imagine a better consulting company to work for, especially if your focus is around Microsoft and .NET.

 

One of Magenic’s core tenants is to try and find “cool work”. Obviously that’s not always possible, because each individual defines “cool” differently, and there are business realities around consulting that simply can’t be ignored. But just the fact that this is one of the company’s core tenants says a lot!

 

So here’s the deal. If you live (or would like to live) in the Boston, Atlanta, Chicago, Minneapolis or San Francisco areas, and if you’ve got .NET skills, and if you want to escape the politics of IT in exchange for the life of a consultant then this is an excellent time to see if Magenic is the right place for you.

 

If you are interested, just send me an email and I’ll forward it on to one of our recruiters (kind of a fast-track offer :) ). Of you can contact recruiting directly through the web site.

Saturday, August 05, 2006 2:17:13 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, August 02, 2006

In a previous post I made a reference to the EU anti-trust case. Stefan asked me to clarify my statement:

 

Could you please explain more detailed what you mean by "will likely do serious harm to European consumers"? As I know the European antitrust suit against Microsoft is to strengthen consumer rights. The charge against Microsoft is that they use their monopoly in OS and undocumented functions in their OS to push their own products. Why should it do harm to European consumers if Microsoft has to offer an OS without Internet Explorer and without Mediaplayer, or to open undocumented functions?

 

Stefan, I realize that the purported purpose of the anti-trust action is to strengthen consumer rights. Yet for the most part, the real result is to protect the "rights" of Microsoft's competitors, not consumers. And perhaps you can't do one without the other - that could be the case.

 

But consider this. In the US anti-trust findings, Judge Jackson was very clear that computer operating systems are a "natural monopoly". That market forces exist that have, and will, create a monopoly in this space. You can read the findings yourself, just search for the term “monopoly” and you’ll get close to the relevant section.

 

The reason for the natural monopoly is sound: it is very expensive for organizations to support varied platforms. Thus they standardize on as few installation sets as possible - preferably one client and one server configuration. So an organization will standardize on Windows XP, or on Windows XP without IE or Media Player, but not both.

 

But then the effect spreads, and this is where consumers get hurt. ISVs build software for the broadest market segment, because that is the most cost-effective approach. So they look at the market and see that the majority of systems are real Windows XP and so they build for that. Only if there's enough outcry from the XPN users will they port their software to run on XPN. The XPN user base needs to be able to find the cost of porting, plus the normal profit the ISV would have made.

 

This causes a feedback loop. Users of XPN always feel like second-class citizens, because they always get software later than real XP users. So when they purchase their next OS, they are more likely to buy real XP rather than the version that gets less ISV support.

 

People don't buy computers for the OS after all - they buy computers for the apps they want to run, and those apps come from ISVs.

 

It is this same effect that causes comparatively slow adoption of the Mac or of Linux as a desktop. Compared to Windows, there’s a dearth of real applications for these other platforms, and the reason is economic.

 

So “getting rid of” the monopoly isn’t a viable goal. The only realistic approach is to manage the monopoly, because destroying it would merely result in some other company rising to take its place – purely due to these economic factors.

 

With that background, I’ll explain why I think the EU’s actions are likely to hurt consumers – just like some of the proposed US actions from 6 years ago would almost certainly have hurt consumers.

 

Restricting the inclusion of the IE and Media Player user interfaces is, I think, immaterial. But the EU is restricting Microsoft from including the underlying components on which they are built. These underlying components are also available to ISV’s, and most of us consider them simply part of the Windows operating system.

 

So Windows XP N, and future crippled versions of Windows mandated by the EU merely cause an artificial split in the operating system. One which any sane organization would ignore, because it is very clearly out of the mainstream (see the natural monopoly discussion above).

 

Of course the reality is that only a very few applications rely on the API exposed by Media Player’s libraries, so that isn’t such a big deal today. More applications rely on IE libraries and that can be more problematic.

 

The bigger issue is the precedent, because further bifurcation of the OS over time will merely make Windows Vista N (or whatever) more marginal.

 

But still, where’s the harm to consumers?

 

  1. There’s harm to the uneducated people who are naïve enough to buy the government-mandated, crippled versions of the OS. They’ll find themselves unable to run certain apps and won’t know why.
  2. There’s harm to all of us, because it costs Microsoft money to build these OS variants – and to test them, and to test all their other products against them (like Money, Visual Studio, SQL Server Express, and on and on – they all must be tested against this crippled version of the OS along with the real OS). Someone must pay for this development and testing.

    Microsoft has been criticized for selling XPN at the same price as XP. Really they should charge more for it, because it is merely a cost to Microsoft. The EU prevents that (as they need to), so it is sold at the same price. If Microsoft were to sell XPN at a lower price, they’d need to raise the price of regular XP to subsidize XPN in order to maintain the same profit margin they make today.

    Software is fundamentally different from physical goods like a car – having fewer options is not cheaper, it is more expensive…
  3. There’s harm to consumers of 3rd party apps that use any features missing from the crippled versions of the OS. They must spend extra time and money compensating for the lack of those features – either through installer UI support to get the user to reinstall the missing code, or by rewriting their app to use a non-OS equivalent API that they can install themselves. This extra cost to the ISV ultimately gets passed along to consumers as a higher price.

    Of course this presupposes that the XPN market is big enough for the ISV to actually care. If not, we’re back to the economic factors causing the natural monopoly in the first place. And even if the XPN market is big enough, XPN users will likely get their software later, and with less convenience during install and so they’ll be less likely to buy XPN in the future – again reinforcing the natural monopoly.

 

As a totally separate issue, the EU is also following the US courts in mandating that Microsoft release better documentation of its APIs. I don’t necessarily believe that this harms consumers (with one exception, so read on).

 

I also am not entirely convinced that forcing the release of documentation helps consumers either – at least not nearly as much as it helps Microsoft’s competitors. Only time will tell on this point.

 

Since browsers and media players are free, there can be no help for consumers in these spaces; at least from a cost-of-acquisition perspective. It may be that some competitor will create software that is more capable, easier to use, cheaper to maintain/support or something like that – in which case I’ll happily acknowledge a benefit to consumers.

 

But to date, it is very hard to find third party software that integrates as well as Microsoft’s set of software. Just try to copy-paste from Word into a rich text editor in FireFox as compared to IE to see what I mean… Both work, but IE tends to work substantially better.

 

Of course you can’t blame third parties for limiting their coupling to Microsoft’s APIs. And this is where things (to me) get puzzling. I work very hard to limit my exposure to Microsoft technologies, and I try to only use their APIs at the surface level. Why? Because Microsoft owns those APIs and changes them over time – and I don’t want to absorb the cost of compensating every time they change something.

 

This is why CSLA .NET, for instance, abstracts things like Enterprise Services and System.Transactions and Remoting and Web Services. Because these are all fluid APIs, and tightly coupling your business application to those APIs is costly. CSLA .NET offers a buffer between them, and the business code we all create and maintain.

 

This, I think, is also why FireFox has limited copy-paste capabilities when compared to IE. It is quite likely that they’d need to take a deeper dependency on a Windows API to have comparable functionality, and that’d make them vulnerable to Microsoft changing things over time.

 

And so here we arrive at the one possible cost to consumers of Microsoft providing more open documentation of its deeper APIs. Documentation doesn’t equate to stability. Just because they are documented doesn’t mean they stop changing. Any software that does accept a dependency on these APIs is even more subject to change than normal software – and we all know the pain of API changes to normal software.

 

So yes, third party apps may become more integrated than before – but they’ll almost certainly cost more, because that integration (coupling) has a high cost to the ISV creating the software, and they’ll need to pass that along to consumers.

 

My guess is that very few ISVs will actually use these deeper APIs. These companies are out to make a profit too, and so they’ll weight the cost of coupling/integration against the benefit of increased sales and determine, case by case, whether they can increase sales (or prices) enough to justify the costs of tighter coupling and its attendant vulnerability to change.

 

Yes, this is a weaker argument – and personally I think the more open Microsoft is in documenting its APIs the better. My real point here is that it isn’t just all goodness and light. There is a serious tradeoff to actually using the APIs that can’t be ignored – and which, I think, will ultimately negate any “benefit to consumers”.

 

So if you’ve stuck with me this far, I’ll summarize: I think the EU went too far by forcing the creation of a crippled OS. I think both the US and EU courts are doing a fine thing by forcing Microsoft to document more of its APIs, but I doubt that will actually help consumers as much as a few ISVs and some competitors.

 

I haven’t even touched the OEM market, and what the courts have changed there – generally for the betterment of consumers. With luck Microsoft is really learning to live within these boundaries (they have a 12 step program after all :) ), and consumers will continue to see benefits in this area going forward.

 

So to close, my primary criticism of the EU is around mandating the creation and support of a crippled OS. There is no upside for consumers there, just extra cost and pain.

Wednesday, August 02, 2006 10:52:43 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, August 01, 2006

Maintaining CSLA .NET, along with the ProjectTracker sample app, in both VB and C# is challenging. I've blogged before about how tedious it is converting C# to VB or visa versa, and how it slows down progress on the framework.

For CSLA .NET 2.0 I was fortunate enough to have the help of Brant Estes from Magenic, who put in amazing time and effort to keep the C# code in sync with the VB code through the development and writing process. There was no way I'd have completed the books and framework on schedule without his help!

But recently I've been playing with a set of tools from Tangible Software Solutions: Instant VB and Instant C#. By way of disclaimer, I got free licenses to these tools thanks to Tangible, and that's why I've been using them. But having used them, I would suggest that they are certainly worth the cost for anyone who needs to convert code one way or the other.

I have been very skeptical of language conversion tools. By and large the results don't look "right". Convert VB to C# and you get working code, but not the kind of code you'd write by hand. It is even worse when converting C# to VB - the results look like C# without the semicolons, and don't resemble real VB code hardly at all...

Now I'm not ready to say that Instant VB/C# are perfect, but they are pretty darn good. Better still, I have been providing feedback to Tangible about what I wish was different, and the speed at which they have responded by improving the tools is excellent! Seriously, I think they've given me 2-3 new builds just in the past couple weeks - each one making my life easier.

I'm using the tools in per-file mode, translating individual CSLA .NET source files from C# to VB and from VB to C#. The VB to C# conversions are quite good, and there are only a couple things I'm having to do to the resulting code (clean up the using (Imports) statements, and rename instance variables because I use a 'm' prefix in VB and a '_' prefix in C#).

The C# to VB isn't quite as smooth yet, but it is getting rapidly better. Tangible is working on an enhancement to translate several common string and type conversion patterns into VB equivalents (Len(), CInt(), etc.) I believe that'll be an option, so if you prefer the C# approach even in your VB code you don't need to worry. Once that is working, I expect to be pretty happy. Even so, I'll need to change instance variables because of my choice of different prefixes - but that's really my issue :)

The thing is, the time savings for me is tremendous. But what makes me write this blog entry is the fact that the resulting code really does look like the kind of code you'd write by hand - and for me that's the true test.

Tuesday, August 01, 2006 1:43:49 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  |