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...

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 (http://ndoc.sourceforge.net) 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.

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.

Every now and then I get asked for career advice – often from people just getting into the computer industry, but sometimes from experienced developers who are considering getting into writing, speaking or similar activities.

My overarching career advice is to be patient, focused and persistent. There really is no substitute for experience, so patience is important. Though there's no substitute for experience, a focused person can learn more in a year than someone who's just coasting through a job from day to day. All that said, you never get anywhere if you don't keep steady pressure on yourself and your surroundings to move slowly toward your goal, so persistence is key.

In the Clinton-era economic boom I encountered numerous people with 0-3 years experience as a developer who wanted to be an “architect”. Now! Instantly! That is an absurd concept, since an actual architect can only function due to having years of experience on many different types of project in different settings and environments. There really is no substitute for experience.

However, I’ve worked with people who have 5-7 years of experience that are absolutely qualified to be application architects. I’ve also worked with people who have 10+ years of experience that are not qualified for anything beyond the developer role.

What’s the difference? Focus.

Some people have a career, others have a series of jobs. People who have a career understand that everything is a learning experience, and that focusing on the benefits of each task or job is only good in the long run. People who just work in a string of jobs don’t have this focus and don’t learn nearly as much.

Like most people, I’ve had my share of crappy projects where I worked on old technology rather than the newest and best stuff. But I’ll tell you that each and every one of those projects taught me something. Maybe not about some specific tool, but often about business, or software design, or architectural principals.

To be truly successful in the computer industry you need to understand far more than just tools and design patterns. You need to understand the interactions between users, and systems, and networks, and operating systems, and tools, and fads/trends. You need to appreciate the cyclic nature of our technology so you can recognize when some “new” thing is an upgraded rehash of an old thing (like SOA and procedural programming).

These things only come through focus. Focus on your career, not just on the job/project at hand. A career is a long-term play. Who cares if you are a developer for a few years before becoming a lead, and then an architect? We’re talking about a 30-40 year span of time here, so 5-10 years to become an architect is nothing.

Yes, I know that careers used to be a 30 year proposition, but due to longer lifespans and the erosion of retirement security (e.g. the impending crash of social security and the destruction of pensions due to things like Enron) most of us (in the US at least) can expect to spend more like 40 years in the workforce in one capacity or another. Personally I’d rather spend more time doing cool computer stuff and less working at McDonalds as a “returning worker”, so I stay focused on computers and automation.

What I’m getting at here, is that things take time and effort. And we have time, and you can choose to put forth effort. So that’s OK.

But while you must be patient, you absolutely need to keep pushing toward your long-term goals. Persistence is what makes your patience and focus pay off. Purely patient people can succumb to inertia. Purely focused people can be sidetracked by frustration. But persistent people have the ability to patiently focus over the long-term in order to get where they want to be.

In some previous posts on service-oriented architecture (SOA), I got comments from various people indicating that SO could/should be applied inside applications as well as between applications. I am skeptical about this - here's why.

Attempting to apply service-oriented concepts inside an application is non-trivial. This is exactly what we tried to do in FORTRAN, C and other languages years ago.

At the time we all argued that it was a good idea - procedural programming made a lot of sense. If you passed all required data in via paramters, and got all data out as a result then procedures were a great way to encapsulate behavior. In this context a procedure of yesteryear and a service of tomorrow are really the same thing.

Of course it didn't actually work that way. Packaging all the data into the parameters was often a huge task, and so virtually everyone cheated by using a common block of memory or other global variable techniques. Thus procedural programming was brought to its knees, because procedures didn't “own” the data on which they operated.

This is a core flaw in object-oriented (OO) designs as well. It is very common to pass an object as a parameter and have some method act on the object. But what you really pass is an object reference. The actual object is conceptually similar to a common block in that case.

Now I agree that OO avoids many flaws of procedural programming, but the fact that methods end up acting on the same physical set of data (objects) can be problematic.

So to apply SO (service-oriented) concepts inside an application means that we're going to take the procedural approach from FORTRAN, but this time we're not going to cheat. Instead we're going to package all the required data into a message (not an object, because the message must be passed by value!!!) and pass it to the procedure (service).

As with FORTRAN years ago, I agree that this could be done. But we didn't have the discipline then, and I very much doubt we have the discipline now. It is just too damn much work to create an XML document (or whatever) each time I need to call a method, and then to unpack an XML document to get at the result. It is simply unrealistic to expect that developers are going to go through this much work.

And people today complain about code bloat. Think of the bloat we're talking about here. Rather than putting an integer on the stack to call a method, we're now going to put the integer into XML and put the XML on the stack? Good thing Moore's Law is out there to save our collective asses...

This is not to say that SO won't work between applications. In that case it will (I think) work very nicely, because you can't cheat. It isn't possible to use a common block or reference to an object across process or network boundaries, so we have to pack parameters and pass them by value.

In the end, SO is what FORTRAN and C were meant to be - and without the possibility of cheating it might really work. Long live procedural programming!

Pat Helland from Microsoft is a recognized expert in the emerging area of Service-Oriented Architecture. His new paper is quite thorough...

Data on the Outside vs. Data on the Inside

The service packs are:

Microsoft .NET Framework 1.0 Service Pack 3 (SP3)

Microsoft .NET Framework 1.1 Service Pack 1 (SP1)

Microsoft .NET Framework 1.1 Service Pack 1 (SP1) for Windows Server 2003

These services packs increase overall security, and support changes made to Windows in Windows XP SP2.

Years ago it was Carl and Gary's that was the central hub for the VB community. The place we all started browsing and then jumped off to other locations. There really hasn't been an equivalent hub (or portal) for a very long time.

But I think there's hope - check out Robert Green's blog entry on the new VB community site updates.

Robert has been working (along with Duncan) on this for quite a while now, soliciting input from a lot of people in the VB community - including authors, speakers and others. The site has been slowly evolving, and now is really starting to show some great promise as a central hub for the VB community.

OK, now I feel better. Perhaps I jumped the gun with my previous post.

Rich Turner gave an awesome presentation – totally on the mark from start to end.

He was very, very clear that the prescriptive guidance is to use asmx (web services) to cross service boundaries and to use Enterprise Services (COM+), MSMQ, Remoting or asmx inside a service boundary.

Note that inside a service might be multiple tiers. Multiple physical tiers. You might cross network boundaries (though that should be minimized), but that’s OK. This is all inside your service, within your control. Since it is inside your control, you should choose the appropriate technology based on all criteria (such as performance, transactional support, security, infrastructure support, deployment and so forth).

This is the best and most clear guidance I’ve heard from Microsoft yet. Very nice!

I’d laugh except that it makes me want to cry.

I’m at a Microsoft training event, being briefed on various technologies by people on the product teams – including content on Indigo.

The unit manager gave an overview, and someone asked about the recommended architecture guidance around today’s Remoting technology. He reiterated that the recommendation is to only use it within a process. This, after he’d just finished pointing out that there are scenarios today that are only solved by remoting.

Say what?

Then several other Indigo team members covered various features of Indigo and how they map to today’s technology and how we may get from today to Indigo. Numerous times it comes up that Indigo incorporates much of the Remoting model (because it is good), and that most code using Remoting today will transparently migrate to Indigo when it gets here.

So what now?

First, the prescriptive guidance is nuts. They are saying conflicting things and just feeding confusion. Remoting is sometimes the only answer, but don't use it?

I'm sorry, I have to build real apps between now and when ever Indigo shows up. If Remoting is the answer, then it is the answer. End of story.

Second, it turns out that you are fine with Remoting as long as you don’t create custom sinks or formatters for Remoting your code will move to Indigo just as easily as any asmx code you write today (which is to say with minimal code changes).

And of course you should avoid the TCP channel and custom hosts – use IIS, the HttpChannel and the BinaryFormatter and life is good.

Finally, (as I’ve discussed before), Remoting is for communication between tiers of your own application. If you are communicating across trust boundaries (between separate applications) then you should use web services – or better yet use WSE 2.0.

Conversely, if you are using web services or WSE 2.0, then you have inserted a trust boundary and you shouldn’t be pretending that you are communicating between tiers – you are now communicating between separate applications.

Though not strictly a computer thing, I have a classic tale of customer service. And hey, customer service is an issue for everyone, all the time. As computer professionals we provide a service to our customers, whether internal or external. And providing good customer service means we get better raises and/or get to keep our job.

This tale of customer service is actually two interlinked stories. They illustrate that customer service is all about how you treat the customer. It is all about interpersonal relationship and interaction.

Many years ago I changed the oil in my car myself. My wife and I couldn’t afford to pay to have it changed, and it wasn’t hard to do on cars built in the 70’s and early 80’s. But over time it became harder and harder to dispose of the used oil, and my income improved as my career moved along.

So eventually we started going to Valvoline Rapid Oil Change. They were quick, efficient and inexpensive. More expensive than me doing it, but by this point in life it was worth the extra money. After using their services for quite some time, they offered to change the PVC valve in our car. It was a $6 part. Not overly hard to change, and their price wasn’t much higher than the price of the part itself. In other words, it seemed worth it, so we said sure, go ahead.

In those years Minnesota required annual emissions testing for all cars in the Twin Cities area. Our test was scheduled for perhaps a month after the PVC valve had been replaced. And the car failed. Of course the state test doesn’t say why the car failed, just that it failed.

So off we went to the Chevy dealer. $60 later it turns out that the emissions failure was due to a faulty PVC valve.

Now I knew darned well that the valve was new. After all, Rapid Oil Change had just changed it less than a month before. So I went over to the oil change place, with their receipt for the PVC valve, the state emissions failure form and the dealer receipt showing the work done at the dealer.

I asked to talk to the manager. He didn’t look happy, and as I explained the story, he looked less happy. Before I could even explain where I hoped this conversation would go, he cut me off and told me that there was no way he could know if their PVC valve was faulty or if the problem had some other root cause.

In other words, he shut me down. No apology, much less offering to defray the $60 his shop had cost me.

In all the years since then we’ve never used Valvoline Rapid Oil Change. Any time I get a chance, I tell people to avoid the chain. Just by my wife and I not using them, they’ve certainly lost more than the $60. And I like to think that I’ve cost them other business as well, thus hopefully providing some just punishment for employing such a crappy manager and for installing faulty parts.

Contrast this to an experience I had just this past week. Last weekend we bought a small pop-up camper trailer so it will be easier to go camping as a family.

The trailer has a round 6-pin wiring plug for the lights. It has the 6-pin plug so it can get power directly from the car alternator/battery and thus it can charge the deep cycle battery in the camper while we drive down the road. Unfortunately my van has a flat 4-pin connector, which works great for most small trailers (like my boat trailer), but doesn’t match up to the 6-pin.

I figured I could rig up an adapter that would at least get the lights working. My thought was that I just didn’t need to recharge the battery from the van, and that it would be cheap and easy to get the lights working.

It turns out that modern cars are finicky and have complex wiring… They aren’t nearly as easy or fun to work with as my 1976 Datsun F-10, or my 1987 Cavalier… So I managed to blow out the fuse for my tail and brake lights on the van, and I still didn’t have the trailer working right.

I called around and ended up going to Burnsville Trailer Hitch, a specialist in these sorts of things. $110 later I had a fully wired 6-pin connector on my van, along with a 6 to 4 converter for my boat trailer. I thought that was money well-spent, since I’d explored running power from the battery back to the plug myself and it would have taken me far longer than the 45 minutes it took them.

But my story isn’t done. Here’s the catch. When I got home, I tried the plug and it didn’t work. The signal and brake lights on the trailer just didn’t work.

I called back to the store, and they offered to look at the problem if I brought the van back. I wasn’t totally thrilled, since we’re talking about a 15 mile drive each way, but there was nothing to be done. Off I went.

About 10 minutes after I got there, the guy comes in and says that there’s this converter unit that safely combines the signal and brake light wires from the van (which has separate bulbs for signal and brake) into a single pair of wires for left and right on the trailer (which has one bulb on each side for signal and brake). Turns out this converter was blown.

Now I knew about the converter, having wired one into my previous car. With him pointing out that it was blown, I strongly suspected that it was my doing, from my earlier attempt to wire the trailer.

Over my protests, he said they’d replace it for free. Seriously, I protested a bit, saying that it could easily have been my fault. His answer? It could have easily been their fault since they might have blown it when they did the wiring for the 6-pin connector.

So here we have a store with awesome customer service. I was and am impressed and will recommend people go there when ever it is appropriate.

But here’s the real kicker. The oil change place pissed off a regular customer, losing not only me and my wife, but everyone we can convince to avoid the place. The trailer hitch place has no reason to expect I’ll ever return. After all, how often do you need a trailer hitch? Yet they were professional and went above and beyond the call to provide great service.

As I said to start, I’m not sure this has anything to do directly with computers, but I’ll bet you that if you treat your customers like Burnsville Trailer Hitch that you’ll have happy customers, get better raises and have a more secure job overall!

The MSDN VB community site has featured my blog - which I think is pretty cool.

For those who don't know, the VB team at Microsoft has started assemblying a community portal site for VB developers at http://msdn.microsoft.com/vbasic/community/.

They already have some cool content, including relevant blog listings, links to sites with useful code, tips and tricks and so forth. And they plan to do more in the near future, including some more interactive content so we, as the community, can help create and manage some of the site's content.

I think this is an excellent step on the part of the VB team to help support the huge VB community, and I appreciate it. Thanks guys!