Rockford Lhotka

 Friday, October 1, 2004

It seems that has a debate going this week about O/R Mapping. As part of the discussion, one of the invited debaters made the following comment about CSLA .NET:


“…everyone just "loves" CSLA, afterall its got every feature imaginable, was created by one of the best "experts", is the subject of books and user groups -- and yes there are code gen templates for it. Now don't get me wrong, I think Rocky is a great speaker and teacher (and great in person too -- I have met him), but I think he would agree that CSLA is an example for teaching how to do something and should not really be the expected to be perfect out-of-the-box -- and its not. I've personally seen a project spend way too much time and effort doing things because they chose this route -- they had to constantly go and add/remove/modify pieces to their chosen framework -- and I've heard many others that have similar problems.” (link)

- Paul Wilson


It is not the most professionally phrased comment, but this gentleman has previously made similar comments in other forums as well, so I thought I should provide an answer.


I think it is important to note up front that Mr. Wilson sells an O/R Mapper tool, and so has some bias. It is also important to note that I have written numerous books on distributed object-oriented architecture, and so I have some bias.


CSLA .NET is intended to be a learning or teaching vehicle. It is often also useful in its own right as a development framework.


Different people write different types of books. For instance, Martin Fowler’s excellent Patterns of Enterprise Application Architecture came out at about the same time as my .NET Business Objects book. In many ways he and I are targeting the same demographic, but in different ways. Fowler’s book stays at a more abstract, conceptual level and teaches from there. My book is more pragmatic and applied, teaching from there.


As an aside, I find it wonderful how some of the patterns in Fowler’s book can be found in CSLA .NET. I think this goes to show the power of the design pattern concept – how patterns emerge in the wild and are documented to help provide a more common language we can all use in future discussions.


But back to books. We need books that give us broad theory and concepts. We also need reference-oriented books that give us basic usage of .NET, C# and VB. And we need books that try to span the gulf between the two. This is where I’ve tried to live for the most part – between the theory and reference content. To do this is challenging, and requires that the theory be distilled down into something concrete, but yet rich enough that it isn’t just more reference material.


The way I’ve chosen to do this is to pick a way of creating distributed object-oriented applications. Are there other ways? Oh yeah, tons. Are some of them good? Absolutely! Are some of them bad? Again, absolutely. Is CSLA .NET good? It depends.


Certainly I think CSLA .NET and the rest of the content in my business objects books are good for learning how to apply a lot of theory into a complex problem space. I think that many readers use ideas and concepts from my books in conjunction with ideas from Fowler’s books, the GoF book and lots of other sources.


A side-effect of writing a book on applied theory is that the theory does actually get applied. This means that the book includes a pretty functional framework that can help build distributed object-oriented applications. This framework, CSLA .NET, can be useful as-is in some scenarios. There’s a vibrant online forum for discussion of my books and CSLA .NET where you can find numerous examples where people have applied the framework to help solve their problems.


Many of those people have also modified the framework to better suit their needs or requirements. This is nothing but good. In several cases, modifications made by readers of the books have been applied back into the framework, which is why the framework is currently at version 1.4, where the book described version 1.0.


Does CSLA .NET fit every need? Of course not. No tool meets every need.


It is particularly good at creating performant, scalable line-of-business systems that involve a lot of data entry and business rules and relationships. It supports people who build a good object-oriented business entity model, because it provides for virtually unlimited flexibility in translating the object data to arbitrary (relational and/or non-relational) persistence targets (databases, etc).


It is not particularly good at creating reporting systems, large batch processing systems or systems that are very data-centric and have little business logic. There’s also a cost to the data mapping flexibility I mentioned as a benefit – because with that flexibility comes more work on the developer. If you have either a non-complex data source or you are willing to tie your object model to your data model then CSLA .NET isn’t ideal because it requires that you do more work. If you want your object model to mirror your data model then use a DataSet, that’s what it is designed for.


But the real thing to keep in mind, above all else, is this: there is a set of functionality that must exist to build distributed object-oriented enterprise applications. This includes data persistence, UI design support, business logic, organization of layers and tiers, state management and more.


The issues that I address in my business objects books and CSLA .NET are addressed in every enterprise application. Whether formally or informally, whether through reusable or ad-hoc implementations – everything I address happens in every enterprise app. (And a whole lot more things I don't address are in every enterprise app!!)


The idea that CSLA .NET has “got every feature imaginable” seems to imply that it has extra stuff you don’t need. The fact is that you will address every issue it covers one way or another, plus numerous other issues. You might address them differently that I did, and that’s great. But you will address them.


You can address them in an ad-hoc manner in each app you write. You can address them through a framework, or you can address them through tools. You might address them through a combination of the above.


But I’ll say this: the ad-hoc approach is poor. You should opt for a solution that provides reuse and consistency. There are numerous ways to do this, CSLA .NET is one and I imagine that Mr. Wilson’s O/R mapper tool is another. And there are various commercial frameworks and other O/R mappers out there as well. You have a lot of choices – which is indicative that this is a healthy segment of our industry.


The fact is that at some point you need to make hard decisions within your organization that move from the theory of design patterns and architecture down to the practical and pragmatic level of code, and you only want to do that once. It is expensive, and it does nothing to solve your actual business needs. All this code that does data persistence, layering, tiering, data binding and whatever else is just plumbing. It is necessary, it is costly, it is time-consuming, and it provides no direct business value.


And be warned – if you buy or otherwise acquire a framework or tool set (CSLA .NET, O/R mappers, whatever) you will almost certainly need to modify, extend, add or remove bits and pieces to make it fit your needs. If you do this by buying a black-box component of any sort, you’ll end up extending or modifying around the component, while if you acquire one that includes code you may opt to make the changes inside or outside the component.


Obviously you can acquire a component that does less work for you – something targeted at a narrow task. In that case you might not need to modify it, but you must face up to the fact that you will need to write all the other stuff that it doesn’t do. It isn’t like you can escape the requirement for all this functionality. Every app has it, whether you do it in a reusable form or not is up to you!


So when it comes to frameworks, O/R mappers and all this other plumbing: do it once – build it, buy it, cobble together products to do it. Whatever suits your fancy.


Then get on with building business apps and providing actual value to your organization.

Friday, October 1, 2004 2:54:40 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I work for Magenic Technologies. Magenic is one of the nation’s leading software development and consulting companies focused on Microsoft technology, and I feel comfortable saying that we employ some of the best consultants in the industry.

Today Magenic announced that they acquired Empowered Software Solutions (ESS) in Chicago.

Personally I'm very excited about this event. I've known Keith, Tammy and Norm (the founders of ESS) for many years and it is very exciting to get to work with them and all the Chicago-based consultants. ESS has a great (and well-deserved) reputation in Chicago. That reputation will help spread Magenic's national presence into the Chicago area.


Friday, October 1, 2004 9:59:47 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, September 28, 2004

There’s a lot of talk about Service-Oriented Architecture (SOA), and Service-Oriented Programming-related constructs like web services and SOAP. There’s even a bit of talk about Service-Oriented Analysis. But where’s the discussion of Service-Oriented Design?


I am quite convinced that service-orientation (SO) is no less of a force than object-orientation (OO). For over 30 years our understanding OO has been evolving and slowly, ever so slowly, gaining mindshare in the industry. I think we can apply a (slightly modified) Grady Booch OO quote to SO as well:


“Let there be no doubt that service-oriented design is fundamentally different than traditional structured or object-oriented design approaches: it requires a different way of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structure or object-oriented design culture.”


The bits in bold are my alterations/additions to this famous quote.


OO includes architecture, analysis, design and programming. Understanding and use of all these components is required to make effective use of OO in an enterprise. Precious few organizations ever pull this off. It requires a major culture and skill shift, which is one key reason why OO is still a popular sideline approach rather than the mainstream approach. (The other key reason is lack of tool support for OO design and programming, but that’s another topic.)


If SO is as big a thing as OO, and I suspect it is, then SO has decades ahead of it on the way to becoming a popular sideline approach for software development. Maybe in that time OO will have become mainstream, but I’m not holding my breath…


As an aside, I very much hope that OOA/D/P do become mainstream at some point. After all, we will need to create services, and a service is just an application with an XML interface (vs HTML or GUI). Creating services requires programming in a more conventional sense, and we’ll end up choosing between data-centric and OO just like today. Personally I really want to see more OO, because I believe it is far superior. But I’m pragmatic enough to know that it is far more likely that services will be created using the same data-centric (Recordset, DataSet, XML document) mindsets that are prevalent today in Windows and Web applications…


In my wilder dreams I envision a new programming language that is specifically geared around the creation of services. It might be neither data-centric nor OO, but rather would directly include language constructs to represent service-oriented concepts. I know Microsoft is grafting some of these concepts into VB and C# through the WSE and Indigo technologies, but that’s like prototyping for something that should come later. Perhaps S#? A language with natural expressions for the ideas inherent in SOA/D/P?


In any case, I am convinced that over the next many years we’ll need to develop SO architecture, analysis, design and programming as disciplines. Processes, techniques and tools will need to be created around all these areas. Perhaps we can do a better job with SO than we did with OO, but that remains to be seen.


But the focus of my question today is this: where is service-oriented design? There’s lots of talk and debate about service-oriented architecture. There’s lots of movement around the creation of technologies (like web services, SOAP and the WS-* stuff) to support service-oriented programming. There’s tiny bits and pieces of discussion about service-oriented analysis. But I have yet to see any serious discussion of service-oriented design.


Service-oriented design is critical. Doing service-oriented programming without service-oriented design is sure to lead to all sorts of unfortunate and unproductive results. Any modern developer knows that you need to translate your architecture into a tactical design for the architecture to be useful. You also know that programming without a design is a sure-fire way to end up with lots of rework and wasted effort.


Service-oriented design isn’t about the enterprise messaging standards, or about the transport protocols (HTTP, MSMQ, Biztalk, etc.). Nor is it about the application of WS-this or WS-that.


Service-oriented design is about the design of service-based applications. It is philosophy. It includes the design of services, service clients and other service-related software constructs. It must focus on concepts like


  • relationships
  • encapsulation
  • message structures
  • data flow
  • process flow
  • coupling
  • cohesion
  • decomposition
  • functional grouping
  • abstraction
  • the service interface
  • the service implementation
  • granularity
  • shared context
  • and more…


Click here for an interesting discussion of procedural vs OO design. I think we need to have a similar discussion around SO design. What is it that makes SO unique and different from procedural/structured and OO design? Intuitively I tend to think that it is unique, but at this point it hasn’t been fleshed out and so we can’t have intelligent or objective discussions about how or when it is different.


In the end, I think that SO will require a comparable culture and skill shift to OO. In other words, moving to SO from either the procedural/structured or OO worlds will require major cultural and philosophical changes, and substantial retraining and relearning.


Does this mean OOA/D/P are dead? Not on your life. Neither are procedural/structured design or programming. Most software today is built using procedural techniques, mixed with half-hearted OO code. As we move (over the next 30 years) toward SO, you can bet that procedural and OO will be along for the ride as well.

Tuesday, September 28, 2004 8:54:07 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, September 26, 2004

As I noted in a previous entry, I rarely read computer books. However, there are exceptions.


People often ask me to suggest good books on object-oriented design. I struggle with this. I have a whole shelf of what I consider to be pretty crappy OO design books. Sure, each of them has a tidbit here and there, but on the whole I wasted a lot of money building a collection of books that sits there gathering dust.


The one book I’ve consistently recommended is David Taylor’s “Object Technology: A Manager’s Guide”. This is an absolute must-read for anyone hoping for success with OO design or programming. Yes, I know it has the dread word “manager” in the title, but don’t let that scare you off. Go buy and read the book. It is not only a delightful read (which is saying a lot for a computer book), but it is full of great ideas and information and ways of thinking.


I just got a new book that I expect will be a favorite. I’m only a bit into it, but I’m so enthused that I’m blogging now rather than waiting for the (sure to be climactic) end of the book.


The book is Object Thinking by David West. Many years ago Mr. West taught college here in Minnesota, and we brought him in to do a multi-day OO design class at the consulting company where I worked. While all of us in the class agreed that his ideas were a bit flakey, the class was absolutely full of great ideas, concepts and approaches.


This book promises to be the same as that class. Mr. West doesn’t pull any punches. He really believes in what he’s presenting, and presents it in a clear and easy to read manner. Sure, the ideas push the limits of what most people consider practical, but they are truly great ideas and deserve serious consideration.


The book reflects a lot of what I talk about in my speaking around the world. This isn’t surprising, since that class years ago certainly influenced my thinking in some very fundamental ways.


This includes ideas like anthropomorphism – where you endow objects with human-like qualities. I do this all the time in my work, and those that have heard me speak know that I do it all the time with objects, computers, networks and all sorts of things. There is tremendous value in giving inanimate entities a voice of their own, as long as you listen to what they say!


And this is the thing. My last statement there sounds flakey. Heck, it is flakey. Mr. West is full of this sort of thing. Don’t let it put you off. I mean it. I’m not much for flakey stuff, but it turns out that some of the flakey-sounding ideas he puts forward are directly useful – at least of you want to do actual object-oriented design.


On a bit of a tangent, Mr. West also tends to use the English language well. This includes using complex words and expressing complex concepts. I love this stuff. My absolute favorite author is Neal Stephenson, mostly because of his absolute mastery of language and imagery. Most computer books (including mine) get edited so they’ll be easier to translate to various other human languages – thus gaining a larger market. While that makes economic sense, it is a truly unfortunate thing, because it guts our ability to use deep language constructs and vocabulary to accurately and viscerally express the concepts we’re discussing.


I am always saying that objects are about behavior, not data. Mr. West has written a book that’s all about understanding that fundamental truth. Get this idea, internalize it, become one with it and you’ll be well on your way to really doing OO design.

Sunday, September 26, 2004 7:55:26 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, September 22, 2004

My son’s 6th grade class recently did an exercise where they voted on the US presidential candidates based entirely on the issues and positions set forth by each candidate. But it was a blind poll – the kids didn’t know who was who. The results were surprising! Click here for my wife’s write-up of the event and the parental reaction.


But it got me thinking. What would happen if you did the same thing with a room full of computer geeks, comparing the features put forth by different tools and technologies. Some ideas:


  • Java vs .NET
  • VB vs C#
  • Web services vs Remoting
  • Web services vs DCOM


And the list goes on…


But seriously. It would be very interesting to see how people “voted” for a technology based purely on its stated feature set rather than on the largely subjective criteria we use in most cases.


By largely subjective I mean, for instance, that most pro-.NET people choose it because it comes from Microsoft. Most Java people choose Java because it doesn’t come from Microsoft. But if you did a blind poll, which would be chosen? I don’t know, but I think it would be an interesting exercise!

Wednesday, September 22, 2004 9:58:14 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, September 21, 2004

I read a lot of science fiction. I travel a lot (which you can tell from my list of speaking engagements) and I find it very hard to work on a plane. You might think I’d read computer books, but I regard computer books as reference material, so I very rarely actually read a computer book, as much as skim it or use the index to find answers to specific questions… Besides, they are all so darn big, and it gets heavy carrying them around airports :)


So what’s the point of this post? I recently read a very excellent book that I believe has a great deal of meaning for the computer industry. Sure, it is science fiction, but it is also paints a picture of what computing could look like if today’s service-oriented concepts come to true fruition.


The book is Vernor Vinge’s A Deepness in the Sky, which is a prequel to A Fire Upon the Deep. Fire is an excellent novel, and was written first. I highly recommend it. However, Deepness is the book to which I’m referring when I talk about the links to the computer industry.


I doubt the links are accidental. Vernor Vinge is a retired professor of Computer Science in San Diego, and obviously has some pretty serious understanding of computer science and related issues.


I should point out that what follows could give away key points in the story. The story is awesome, so if you are worried about having it lose some of its impact then STOP READING NOW. Seriously. Take my word for it, go buy and read the book, then come back.


The technology used by the Qeng Ho (the protagonist race, pronounced “cheng ho”) in the book is based on two core concepts: aggregate systems and the wrapping/abstraction of older subsystems.


First is the idea that all the systems are aggregates of smaller systems, which are aggregates of smaller systems and so forth. This is service-orientation incarnate. If you know the protocol/interface to a system, you can incorporate it into another system, thus creating a new system that is an aggregate of both. Extending this into something as complex as a starship or a fleet of starships gives you the effect Vinge describes in the book.


And this is a compelling vision. I have been in a bit of a funk over the past few months. It seems like our industry is lost in the same kind of rabid fanaticism that dominates the US political scene, and that is very depressing. You are either Java or .NET. You are either VB or C#. That gets very old, very fast.


But Vinge has reminded me why I got into computers in the first place. My original vision – way back when – was to actually link two Asteroids arcade games together so multiple people could play together. It may sound corny, but I have been all about distributed systems since before such things existed.


And Vinge’s vision of a future where massively complex systems are constructed by enabling communication between autonomous distributed systems is exactly what gets me excited! It is like object-oriented design meets distributed architecture in a truly productive and awesome manner. If this really is the future of service-orientation then sign me up!


The second main theme is the idea that most systems wrap older sub-systems. Rather than rewriting or enhancing a subsystem, it is just wrapped by a newer and more useful system. Often the new system is more abstract, leaving hidden functionality available to those who know how to tap directly into the older subsystem directly.


This second theme enables the first. Unless systems (and subsystems) are viewed as autonomous entities, it is impossible to envision a scenario where service-oriented architecture is a dominant idea. For better or worse, this includes dealing with the fact that you may not like the way a system works. You just deal with it, because it is autonomous.


To digress a bit, what we’ve been trying to do for decades now is get computers to model real life. We tried with procedures, then objects, then components. They all miss the boat, because the real world is full of unpredictable behavior that we all just deal with.


We deal with the jerks that use the shoulder as an illegal turn lane. We deal with the fact that our federal tax cuts just get redirected so we can pay local taxes and school levies. We deal with the fact that some lady is so busy on the cell phone that she rear-ends you at 40 mph when you are stopped at a red light. We deal with the fact that the networks run R rated movie commercials during primetime when our kids are watching TV.


The point is that people and all our real world systems and devices and machines are autonomous. All our interactions in the real world are done through a set of protocols and we just hope to high heaven that the other autonomous entities around us react appropriately.


Service-oriented architecture/design/programming is the same thing. It has the potential to be the most accurate model of real life yet. But this won’t be painless, because any software we write must be ready to deal with the autonomous nature of all the other entities in the virtual setting. Those other autonomous entities are likely to do the direct equivalent of using the shoulder as a turn lane – they’ll break the law for personal advantage and from time to time they’ll cause an accident and every now and then they’ll kill someone. This is true in the real world, and it is the future of software in the service-oriented universe.


To bring this back to Vinge’s Deepness, the various combatants in the book make full use of both the distributed autonomous nature of their computer systems, and of the fact that the systems are wrapping old – even ancient – subsystems with hidden features. It isn't understanding a computer language that counts, it is understanding of ancient, lost features of deeply buried subsystems that gives you power.


We are given a vision of a future where systems and subsystems are swapped and tweaked and changed and the overall big system just keeps on working. At most, there’s adaptation to some new protocol or interface, but thanks to autonomy and abstraction the overall system keeps working.


It is perfect? Absolutely not. In fact I never saw the big twist coming – nor did the protagonists or antagonists in the book. The overall system was too complex, too autonomous. There was no way they could have anticipated or monitored what eventually occurred. Very cool (if a bit scary). But I don’t want to spoil it entirely, so I’ll leave it there.


Go read the book, hopefully it will inspire some of the same excitement I got by reading it. It certainly gave me an appreciation for the cool (and scary) aspects of a truly service-oriented world-view!


Tuesday, September 21, 2004 7:59:04 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, September 18, 2004

Some people are still trying to have browser wars. Now it is apparently between Firefox and IE. What a misguided concept.


Star Trek covered the issue years ago in an episode titled “Let that be Your Last Battlefield” (which is probably the only good episode in all of season 3). In this episode there are two characters. One, named Lokei, has black skin on the left side and white skin on the right. Another, Bele, has black on the right and white on the left.


The point of the episode is to illustrate just how inane the concept of racism really is. But the lesson is easily extended to any scenario where meaningless differences are used as a divisive technique. This is true of the silly arguments between VB and C#, Ford and Chevy, and is equally true of the so-called “browser wars” of today.


When two things are identical except for superficial differences then it is a massive waste of time and energy to get worked up over who picks which thing. People who consider themselves “superior” for picking on set of superficial differences are simply (not to pull any punches) idiots.


Years ago when I was a DEC VAX guy we used DEC branded VT terminals (VT52, then VT100 and VT220).


Another company, Wyse, had VT terminals that were cheaper so we switched to them. These terminals also had a couple odd features we didn't use – after all, we still had lots of DEC terminals, so we stuck with the common (standard) ESC sequences.


Browsers are the same thing. Since HTML has stagnated (or was that standardized?), it doesn't really matter what browser you use. Who cares? Virtually all web sites out there use HTML 3.2, because that’s the de facto standard that works reasonably well on all terminals – oops, I mean browsers.


The difference between having tabs or not, the specific icons on the toolbar, or how favorites are organized are immaterial. In the end, all the current browsers pretty much understand the same ESC sequences (except now those sequences are HTML – whoop de doo).


Sure, some people are foolish enough to use the browser as a programming platform (as in using client-side script to do a rich UI). Those poor people are stuck with IE (or whatever browser they targeted), but that is a poor strategy anyway. Note the total lack of development tools support for client-side programming. There's not a vendor out there who is encouraging or enabling client-side programming. It is a total dead-end wasted investment in the long run.


No reputable Internet company is foolish enough to go down the client-side script road. Only misguided IT shops are doing this, and they are going to get burned over time...


If you want a rich client, use Windows or GNOME or KDE. That’s what these technologies were designed for!!!! Don’t bastardize a terminal/browser into doing something way beyond its design parameters. That’s like using a duck as a pack animal when there are perfectly good mules and horses standing right there.


In the end, when you look at IE or Firefox, either switch, or don't switch. I honestly don't see where it matters. This is fundamentally the same debate as whether to switch from VT terminal vendor X to vendor Y - only now the price for both products is zero.


IE is black on the left side, and Firefox is black on the right. Other than superficial differences they are the same damn thing.


In the Star Trek episode the two “races” had fought so long and hard that they’d literally destroyed their planet. Lokei and Bele were the only members of their world left alive. Thankfully the “browser war” is unlikely to decimate Earth or even the IT industry, but it certainly does have the potential to waste more time and energy than free products can possibly be worth…

Saturday, September 18, 2004 8:27:26 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, September 16, 2004

From a recent MSDN article on UI design comes this little quote:

“[...] We then discussed two types of UI designs—deductive and inductive. Generally speaking, the former puts the onus on the user to manage and learn a task, while the latter takes on the onus to guide the user through a task. The latter consequently turns out to be a great UI design choice for infrequently used tasks [...]”

I think this is very interesting, because I've seen numerous examples where an inductive UI was used for frequently performed tasks. And while these UIs look very cool, they are really, really inefficient if you have to use them very often...

Thursday, September 16, 2004 5:43:46 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I just had a conversation with a member of a Microsoft product team earlier this week. He said that he wished they were doing something comparable to ndoc in Visual Studio 2005, but they aren't.


For those who don’t know, ndoc ( is a very cool tool that takes the XML comments and assembly metadata from your .NET code and creates MSDN-style help in html and chm format. The XML document support is available in VB if you use vbxc and C# supports it directly. ndoc is open-source software (OSS), and it is very good. I use it on a regular basis and recommend it.


In my mind, the idea that it was somehow bad that Microsoft hadn’t created an alternative to ndoc triggered the question: “Why is it that Microsoft feels the overwhelming need to compete with and replace perfectly good tools that already exist? Especially free ones?”


Not to say that there might not be perfectly good reasons to compete with ndoc on some level. I guess I don't know. But what's the point? To crush the spirit and community effort put forth by some group of loyal .NET developers? That certainly makes little sense...


But I keep forgetting - OSS is evil. Donating time and effort for no immediate monetary return is bad. If you aren’t making money directly off your work then there’s something wrong with you and you should be crushed.


But wait! I am a Microsoft Regional Director (RD) – a relatively small group of people around the planet who help evangelize Microsoft tools and technologies. And I am a Microsoft Most Valuable Professional (MVP) – another group of people around the world who help support the Microsoft community.


The whole point of the RD and MVP programs is for Microsoft to acknowledge people who donate time and effort to Microsoft and the community for no immediate monetary return.


So now I'm conflicted... Donated time/effort is evil when done independently. But Microsoft sanctioned donation of time/effort is encouraged. Say what!?


Honestly, Microsoft just needs to get past this knee-jerk reactionary stance on OSS and realize that it has strong benefits for all of us – including Microsoft.


Part of the recent success of .NET has been due to OSS. Tools like ndoc and a host of others have made .NET development truly productive for many organizations. Productive in ways that even Visual Studio 2005 is unlikely to match. This is only good, as it has spurred adoption of .NET where it otherwise may not have been used.


It is also good in that it has forced some traditionally anti-Microsoft people to rethink their world-view. If OSS can thrive in the .NET space as well or better than it can in the Java space then is .NET really such an evil thing? I’ve personally used the existence and broad support for various .NET OSS tools to bring some Java-focused people to a realization that .NET is a pretty damn cool platform.


And finally there’s the competitive aspect. Microsoft is only good when it has competition. Without competition Microsoft tends to serious lag.


Look at Office and the sorry improvements in that space over the past few years. No competition, and the products get incremental and generally lame improvements (with the exception of Outlook 2003, which is really nice!). I don't think I've used a single new feature of Word since Office 97. I just keep upgrading to stay current, not because I get any value.


On the other hand look at .NET. Due to the competition from Java and J2EE we Microsoft-loyalists now have the (arguably) best programming platform and tools ever created. Not that .NET is perfect by any means, but it is seriously cool and fun and productive!! All thanks to the Java world, which provided competition and drove Microsoft to make radical shifts in tools and technologies in ways that really benefit us in important ways.


And due to the continued pressure from OSS (and other vectors), we’re seeing substantial improvements coming in the 2005 series of .NET tools. For example, integrated unit testing (to compete with nunit).


And I do think this competitive view is healthy, but also frustrating. It is healthy because it drives innovation and integration of cool tools - increasing my productivity. It is frustrating because Microsoft somehow doesn't exude a sense of competition as much as “OSS is evil and must be destroyed” - which is totally counter-productive on all levels.


Competitors aren’t evil, they just are.


I think competition, especially with OSS, should be viewed as a net win overall.


Suppose Microsoft does (at some point) create something comparable to ndoc, but integrated into Visual Studio. We (as users) would get an integrated and probably more polished documentation tool, and the guys who built ndoc would be freed up to go create some new and even cooler OSS tool to fill in some other missing functionality in the Microsoft development tools. Everyone wins – at least if you look at the bright side of things :-)


In the meantime I have work to do - including building some updated online help files by using ndoc.


Thursday, September 16, 2004 9:28:55 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, September 9, 2004

I just love a good discussion, and thanks to Ted I’m now part of one :-)


A few days ago I posted another blog entry about service-oriented concepts, drawing a parallel to procedural design. Apparently and unsurprisingly, this parallel doesn’t sit too well with everyone out there.


I agree that SO has the potential to be something new and interesting. Maybe even on par with fundamental shifts like event-driven programming and object-oriented design have been over the past couple decades. However, I am far from convinced that it really is such a big, radical shift – at least in most people’s minds.


After all, at its core SO is just about enabling my code to talk to your code. A problem space that has been hashed and rehashed for more years than most of us have been in the industry.


Most people view SO as SOAP over HTTP, which basically makes it the newest RPC/RMI/DCOM technology. And if that’s how it is viewed, then it is a pretty poor replacement for any of them…


Some people view SO as a technology independent concept that can be used to describe business systems, technology systems – almost anything. Pat Helland makes this case in some of his presentations. I love the analogy he makes by using SO to describe an old-fashioned experience of coming in and ordering breakfast in a diner. That makes all the sense in the world to me, and there’s not a computer or XML fragment involved in the whole thing.


Yet other people view SO as a messaging technology. Basically this camp is all about SOAP, but isn’t tied to HTTP (even though there are precious few other transports that are available for SOAP today).


Obviously for SO to be a radical new thing, one of the latter two views must be adopted, since otherwise RPC has it covered.


By far the most interesting view (to me) is of SO as a modeling construct, not a technological one. If SO is a way of describing and decomposing problem spaces in a new way, then that is interesting. Not that there’s a whole lot of tool/product money to be had in this view – but there’s lots of consulting/speaking/writing money to be made. This could be the next RUP or something :-)


Less interesting, but more tangible, is the messaging view. Having worked with companies who have their primary infrastructure built on messaging (using MQ Series or MSMQ), I find this view of SO to be less than inspiring.


It has been done people! And it works very nicely – but let’s face it, this view of SO is no more interesting or innovative than the RPC view. The idea of passing messages between autonomous applications is not new. And adding angle brackets around our data merely helps the network hardware vendors sell more equipment, it doesn’t fundamentally change life.


Again, I call back to FORTRAN and procedural programming. The whole idea behind procedural programming was to have a set of autonomous procedures that could be called in an appropriate order (orchestrated) in order to achieve the desired functionality. If we had not cheated – if we had actually passed all our data as parameters from procedure to procedure, it might have actually worked. But we didn’t (for a variety of good reasons), and so it collapsed under its own weight.


Maybe SO can avoid this fate, since its distributed nature makes cheating much more difficult. But even so, the design concepts developed 20 years ago for procedural design and programming should apply to SO today, since SO is merely procedural programming with a wire between the procedures.


So in short, other than SO as an analysis tool, I continue to seriously struggle with how it is a transformative technology.


Either SO is a new RPC technology, enabling cross-network component access using XML, or SO is a new messaging technology, enabling the same autonomous communication we have with queuing technologies – but with the dubious advantage of angle brackets. Neither is overly compelling in and of itself.


And yet intuitively SO feels like a bigger thing. Maybe it is the vendor hype: IBM with their services and Microsoft with their products – everyone wants to turn the S in SOA into a $.


But there is this concept of emergent behavior, which is something I’ve put a fair amount of energy into. Emergent behavior is the idea that simple elements – even rehashed technology concepts – can combine in unexpected ways such that new and interesting behaviors emerge.


Maybe, just maybe, SO will turn out to be emergent by combining the concepts of RPC, messaging and angle brackets into something new and revolutionary. Then again, maybe it is a passing fad, and SO is really just another acronym for EDI or EAI.

Thursday, September 9, 2004 8:42:46 AM (Central Standard Time, UTC-06:00)  #    Disclaimer