September 2005 - Posts
I'll be leaving for the MVP Summit in Seattle tomorrow (tuesday) morning. I hope to see you there, if you're attending as well! 
.
Jason Salas wonders what will happen if Google got into the developer tool business. Interesting thought which I'm sure, among other thoughts, has bounced inside Microsoft's exec's minds a couple of times. Though, with all the hoopla about Google picking up the gauntlet and heading over to Redmond to conquer the first house on Microsoft Way, one would almost forget that it would be a silly business decision to do so.
Microsoft is incredibly powerful. And no matter what old literature you tend to read in bed, David and Goliath's role playing game is fiction, at least when you project it onto modern day's society in general and this situation in particular, simply because Microsoft is beyond Goliath: it doesn't have just two legs to stand on, but 10, or even more. So even if Google rail-gunned some of these pillars directly, it wouldn't bring Microsoft down to its knees, and Google knows: also in this game, ammo is limited.
So what do you do if you're Google? Well, competing directly with your competitor in markets completely dominated by your competitor is, like described above, not very smart, though also not that necessary. You see, to extend the skewed David/Goliath metaphore a bit, Goliath has to eat too. You can, being Google, try to steal his food directly from him when you're in the area but chances are the big arms and legs of Goliath will hit you while doing it and it might be you need some time to recover from those 'interactions'.
A much better strategy is to talk to the people bringing the food to Goliath. They're not armed with big strong legs and it's likely they might be very interested in what you, being Google, have to offer to them. The keyword here is 'interested'. You, being Google, have to offer them something that's worth taking, why would they otherwise switch over to you and leave Goliath without food?
You can of course offer the double of what Goliath offers them, and some of the food-boys & girls might think that offer is one you can't refuse. But will that be enough? You need to persuade all of them, or at least a significant amount. And offering the same goods as Goliath offers them might also have no effect at all. Perhaps the food-boys & girls already have enough and are happy campers with what they got from Goliath. After all, more of the same is still getting the same.
Better is to offer something new. Something which fulfills their wildest dreams. Something which Goliath sometimes mumbled about during coffee breaks or around 3 pm on a sunday morning in a deserted pub but never actually offered. Something which was never seen by the food-boys & girls.
Offering something new, something you didn't think of but the second you saw it you realized: this is it, this is something you really could use and would have wanted ages ago. That's the kind of stuff Google will use to compete with Microsoft. Not in the same markets, but in different markets. Sometimes created for that purpose, sometimes simply in markets which were very small due to the lack of a good product, but in all cases in markets where Microsoft isn't dominant. The net effect is that these new markets can make other markets obsolete or insignificant. I'll get into one example in a second. By starving another market by luring away customers from that market with your own, you can starve a big company which controls that other market, without even competing in that market. The main cause this is possible is that a given market M has become a market based on the solution, not the problem: instead of focussing on the problem and then seeking the best fitting solution to that problem, you start with the solution and arrive automatically in the market of that solution's offering. By making people aware of the problem again and at the same time offering a different solution, you have a big chance the solution you're offering is very appealing, also because you explain the problem very well. This is the strategy I think Google will follow.
An example of such a market could be something which simply makes other products obsolete by offering different functionality to solve the same or similar problems. Take for example information workers in an average office. What do they do, on an average work day? They make sure the information flow inside an organisation keeps flowing. They do that by spending large amounts of time in outlook and office, and the backbone is controlled mostly by Exchange. People on the sales force on the road who want to access that information have to log into the exchange system, probably using a laptop. All employees use PCs, the backbone is stored on large PC's/servers, the whole architecture is controlled, monitored and administrated by a couple of system administrators which have a full time job administrating. No-one wonders if all these pc's and all that software are really necessary. After all, it's pumping data around which is transformed into information, and the access to that information is, in my example, performed through extremely expensive pipelines.
What if that backbone isn't inside your company but on a virtual space in the Google universe? And you get there by simply booting from a CD, within 15 seconds? Or accessing the same system, information and functionality (and more) via handhelds, smart-phones, laptops, even a set-topbox on your TV at home? Don't think in terms of Microsoft Office, but in terms of functionality elements. Which functionality do you need to get things done. By answering that question, you'll find out there are several ways to offer what you need, not just one.
My example above is obviously flawed and not likely what Google will do tomorrow, but I hope you'll see through the metaphore and understand what I mean. The example does illustrate that by offering an alternative which works completely different, you can limit IT costs with a tremendous amount, without jeopardizing the most important thing: keeping the information flow flowing and accessable without paying a huge price.
For the people who misunderstood me in my last posting: I really like Linq as a general purpose system to offer a single interface for accessing enumerable data structures.
My point in my previous posting wasn't to rant about Linq, as I truly like it, my point was that the video gave me the idea as if they believed they had invented something like O/R mapping, an OO overview of your relational model and a compile-time checked query system. I can do that today, so that's nothing unique. 
.
Though, at the moment, every O/R mapper vendor uses his own query system, his own system to map objects, his own system to track changes, his own system to interact with other systems, build in validation, workflow, do serialization/remoting etc. With Linq (that's not: DLinq, but Linq), this can be made more generic: the user can now work more transparent with the underlying engine, from whatever vendor.
So Linq solves an actual problem. Now, DLinq on the other hand is a different story. DLinq might seem it will make things easier, but it carries along some mistakes already known for years by the O/R mapper vendors. I therefore see DLinq as an example implementation, how the Linq system works in practise, how you can extend it into a given direction.
Personally, I'm not that worried about DLinq, I just find it a missed chance for MS to create something great. I mean, instead of solving other problems in the OO world, like cross-appdomain object awareness so server-farm wide object caches can be created so you really can have safe object caching outside the database, it comes with an already surpassed O/R mapper lookalike (DLinq, not Linq). I also wonder why MS comes with DLinq at all, because are they now suddenly convinced everyone should drop the Dataset and move on to an O/R mapping world? As Anders said in the video, it's a future version of ADO.NET, but what about the hardcore table/raw sql focussing crowd? I.o.w.: current ADO.NET building blocks have to stay, you can't drop these out, as you'll then abandone that crowd of people, currently using stored procs and datasets/readers.
Don't think lightly about this: DLinq from MS is a huge paradigm-shift. From service oriented, based on messages and anonymous datasets to domain oriented, with typed domain objects. We'll see how it evolves. I only hope Linq isn't compromised to make DLinq work better, but kept as generic as it is now, so 3rd party vendors can actually use it as our next-gen query language, which is a big benefit for our customers/users.
I just watched this video, where Anders Hejlsberg explains to Channel 9 what Linq is. I couldn't help it but think "Why is everyone at Microsoft doing as if they've invented something new, or hearing from it for the very first time?". Also read the comments below the video on channel 9... I seriously doubt it if some people ever look beyond what they get from Microsoft. 
. I like Linq's general structure, and I think it's a step forward, but please... drop the act as if you all discovered something no-one has thought of before, especially in the department where databases come into play.
Same with the XLinq examples given. I find it interesting Microsoft finally understands that the horrible way the current Xml objects work is something which should be changed. What I also find interesting is that it's a big achievement to be able to finally create elements and attributes in a more convenient way. Anyone who has done some Xml work knows that the first thing you do is to write some wrapper which will produce the elements and attributes at the spot where you want them. Write it once, re-use it everywhere, and even today, not in 200n, n > 6
I'm not that into plugging my own work after making a point, but for creating and using an object-oriented overview of your database(s) and be able to use that with queries which are checked at compile time and are type safe, you don't have to wait till Linq finally arrives. And no, I didn't invent it either nor did a lot of other people in the O/R mapper field. The O/R mapping patent (which uses Xml files ironically, not attributes) states MS invented it, we all know that one of their biggest competitors, Oracle, sells a tool today which is around at least 10 years utilizing this same stuff.
Read more here: Miguel's blog. It's sad that INETA apparently isn't as independent as they claim to be...
Ok, everybody and his/her brother has blogged about Linq already so why not ramble some words about linq here? 
.
First, Linq itself. Linq is cool. It's a system to build language constructs inside C# or VB.NET. For the people who haven't waded through the .docs describing Linq in detail, you can see it as operator overloading on steroids: define your own language constructs with C#/VB.NET language constructs in a typed way, so that you can write simple queries or functions over data, which resolve to your own structures, expression trees, or to plain C#, VB.NET, whatever you can think of.
Ok, so that's cool, we can safely all agree on that.
Now, Microsoft thought... "Hey, everybody is doing that attribute based O/R mapping. Why not do it ourselves?". Together with Linq they build DLink: an attribute based O/R mapper. I couldn't believe my eyes: while every decent O/R mapper moves away from attribute based O/R mapping simply because it's not scalable beyond 1 database, Microsoft moves towards it! 
.
I understand the reason for attribute-based mapping in their case (meta-data in the assembly, which can directly be used by intellisense, compilers etc.) though it's not very flexible to begin with. To see this, consider a domain object, the ol' dreaded 'Customer', and that you map it on an SqlServer table. You give it a good old Guid PK, a nice boolean field 'IsGoldCustomer' which is mapped onto a bit field etc..
Then your client asks you... "You do Oracle too, right?"
You hear yourself mumble through the phone: "Sure, no problem!"
But, next day, when you're starting to work on a port to Oracle, which should be simple, you realize... mapping information inside the domain object, which contains SqlServer specific elements, isn't usable on Oracle. Why didn't you opt for a system which didn't use attribute based O/R mapping!
It's a preview of course, and there's a long road towards final code, but, take it from the field, Microsoft: attribute-based O/R mapping isn't the way to go.
Code project is a great site. From time to time, real gems are posted and it's a shame a large part of the developers out there simply overlook these must-read articles.
One of these gems was posted today: Time-managent tips for developers.
In the past 3 years I now work on LLBLGen Pro, I wrote hundreds of thousands of lines of code, and I wouldn't have been able to do that without a lot of the tips given in the article. A must read.
More Posts