RSS API for IE7 – now we’re talking!

I'm sure this is abundantly apparent to anyone leafing through the articles on this site that I'm a big fan of RSS. Microsoft is finally starting to make some noise in this area, and it's the start of something big. Take a good look at what's happening right now in RSS, because in five years, this is going to make SOAP look like a fad.Ok, some really brief history for those new to RSS:

  • RSS began as a news syndication protocol. News-oriented sites could encode summary info about articles with links to their sites. This allowed "subscribers" to have a "Slashdot news" block on their site. Great viral marketing for both parties. Notice that this is strictly a B2B-type interaction.
  • With the advent of blogs, RSS started getting personal. More sites began using it, and more readers wanted it. Enter the RSS reader (RSS Bandit, NewsGator, etc.). It's now common for people to track dozens of feeds, and RSS feeds begin to displace email newsletter subscriptions. The practice of using RSS just to link back to the "real" article begins to fade (put your content in your feed, or don't bother me).
  • Podcasts. Did you know what a podcast was a year ago? 'Nuff said?

So here we are, early in 2006. What more can happen with RSS?

Lots, really. We're really still in the "early adopter" phase of RSS growth. Microsoft's push will help that along nicely. FireFox has already started to ramp people up on the concept of RSS, and IE7 will accelerate that growth. But there's a lot more to Microsoft's capabilities than are apparent at first.

Check out a couple links from Microsoft:

Using the Microsoft Feeds API This shows the API for the RSS feed that IE7 uses. Not too sexy, but you can see that the API is reasonably comprehensive, and it's getting built into IE7, which will eventually ensure that it's ubiquitous.

Simple Sharing Extensions for RSS and OPML This one's quite a bit fuzzier, but if you squint at it sideways, you can make out the shape of a killer platform. Let me explain:

The point of SSE is bi-directional synchronization. The thing about RSS to-date is that it's been strictly unidirectional. Publish-subscribe. Or don't subscribe. That's it for options. Now, you start opening up the possibility of synching back and forth, and things start to get interesting.

RSS is about to exit the "news" business.

The thing that makes RSS work is the ability to share "articles" in a universal format. As we've moved from news to blogs to podcasts, we're stating to see RSS used to publish "items" instead of "articles". The ubiquitous availability of RSS and the existence of a synching protocol for RSS mean that we've got a kick-ass collaboration engine just over the horizon.

There's a new calendaring app that's hit some Microsoft blogs recently: 30 boxes. Right now, it's best-known for its great use of AJAX, but it's also built to be able to share calendars, and this can give us a great glimpse into what's coming in a big way as RSS matures. Imagine subscribing to someone's calendar using an RSS mechanism, and then being able to update items. Obviously, there's a little matter of security to deal with, but the concept is pretty powerful.

When you consider the online-offline multi-client capabilities that RSS shows right now, this is going to really open up collaborative apps on a new scale. You can imagine how this works for a calendar. Open up the idea of "items" to include contacts, to-do's, etc., -- I hope we'll see stuff like this in the next Outlook. Hopefully, you can see this extending to enterprise stuff, too -- CRM info, stuff that's landing on portals right now, and so on. Clearly, none of these are things that can't be done now, but most of them are things that aren't being done because it's too difficult for users. The next generation of collaboration will marry the ease-of-use of today's best apps to the resilient, flexible infrastructure that RSS brings.

Now, the potholes. I already mentioned security. Versioning will need to be addressed. And finally, the scalability and reliability of Microsoft's RSS store will be mightily tested when this starts to take off. I expect the RSS store to turn into the new registry -- a brilliant idea that ends up being used for stuff far beyond its initial intended use. It'll probably need a little time to be able to handle everything that's going to be thrown at it.

Remember, you heard it here first.

Rant: What does version 0.1 mean?

I'm wading though the shambles of tattered source code left behind by an employee who used to work for another department in my company. It seems I"ve inherited the system that this guy and some of his also-departed co-workers put together for a customer of ours. There's documentation for the system, but nothing that documents anything I'd really want to know, so I'm surfing through the source code trying to soak up some intent, and I find one of the few classes that has any comments. In the comments, there's a version number. It's "0.1".Version 0.1??

What's that supposed to mean? As far as I can tell, this is a lame attempt to divert blame if a bug ever turns up. "A bug? Well, what're you getting so bent out of shape about?? It's only version 0.1!" As if this were really an indemnification against defects, freeing the developer from any real responsibility to get anything right.

What's the big hangup about taking enough responsibity for delivered code that you'll put a 1.0 on it? This wasn't a demo, it wasn't a prototype, and it wasn't still in testing. This code was delivered to the customer, and it's being used in production.

There's a principle at work here about not delivering something half-done to a customer. If you're about to deliver something that's worthy of a 0.1 version number -- stop! Your customer deserves better than this. If you're delivering something that's done, then guess what? You can slap a 1.0 on it with no qualms whatsoever. Let your version number be another clue that can tell you if you're delivering what you're supposed to be delivering.

End of rant.

New: Full-text RSS feed

There are two schools of thought when it comes to RSS feeds: show everything, or publish only "teasers" because you want to drive traffic to the web site by forcing click-throughs from the RSS feed. I've seen arguments both ways, but being an avid RSS consumer myself, I'm a big fan of feeds that push out all content, so I modified my feed to include the full text of all my articles.

Software that works the way it’s supposed to

Sad to say, but I'm surrounded on a daily basis by so much software that doesn't work very well that I'm really surprised when it does work.

My wife just called me with a UPS tracking number -- could I arrange for will-call and go pick it up? The resulting interaction I had with UPS's systems was pretty unique for me, in the sense that it worked, despite the complex systems I know are involved on the other end of the interaction.My wife gave me a tracking number and an 800-number to call - both printed on the slip that UPS left on the door. She could tell from the slip that UPS was trying to deliver a mail-order prescription, and that since the prescription was going to require a signature, tomorrow's delivery would fail too, so she asked me to pick it up at the UPS location.

The first thing I did was to log onto UPS.com and check the tracking number. Why? Just dumb curiosity, I guess. Sure enough, it showed the status as "first attempt made."

So I picked up the phone and dialed the number. An autmated attendant asked me for the number that was printed on the slip. "Oh, great," I thought -- I've been on the losing end of way too many of these engagements not to be skeptical. I didn't have any other options, though, so I read the number, fully expecting to be put on hold for ten minutes, only to be asked for the tracking number again when somebody finally got to my call.

But that didn't happen. Not five seconds after I'd read the number, the attendant came back with information about the shipment (tried to deliver today, going to deliver tomorrow -- is that ok?). I answered, "no" and was asked if I wanted to pick up the package. I was told it was still early enough to pick the package up today, and asked to provide a phone number. So far, so good. Finally, I was asked for a second number in case the first didn't work. I gave my work number, including an extension.

Throughout this exchange, there was a stunning lack of interference. No "please wait while we get the next question ready." No "please repeat your last answer - we didn't understand it." None of that. Not even with my work phone - I figured the extension would mess up the system for sure.

Very, very nice.

Now, I know that somewhere back in the bowels of some UPS data center, cams were turning and gears were whirring. I know that a complex matrix of SOA-compliant software components were exchanging protocols at a blistering pace. I didn't have to, though. I didn't have to give a hoot about routers and message busses, because the system just worked. The technology became invisible.

Just for grins, I updated the tracking page no more than ten seconds after I hung up the phone. Guess what? It showed that the package was being processed for will-call.

Outstanding.

Please, let this be a lesson for all of the customer dis-service centers out there that make me say my phone number, account number, name, whatever, then put me on hold and make me say them all over again when somebody finally gets on the like to abuse me in person.

Please let this also be a lesson to all the stupid automated systems that just aren't ready for prime time.

I know this is a problem for lots of people out there, because there's a major credit card company running a big ad campaign based on a "feature" in their customer service IVR system that lets you press "0" to speak with a real person. That's right, the general state of customer service is so lousy, that just the promise of being able to talk to a person is a major selling point!

Oh, yeah - one more thing. The UPS system promised that someone would call me back to confirm arrangements within an hour. They called in twenty-two minutes.

Well done, UPS.

Hiring – Your most important job

The December 15, 2005 issue of SDTimes has an interesting article on hiring tips and practices. On a couple of points, they hit bullseyes, but on some others, I think a hiring manager can do better. One thing is certain, though - if you are a hiring manager, this may be the most important thing you can do to influence the long-term success of your team, so be sure to give hiring the time and attention it deserves.

Read on for more, including specific improvements to the practices in the SDTimes article and some key traits you can look for in candidates.One of the parts of the SDTimes article I agree with in principle is trying to understand whether a candidate can think outside the box. I do not, however, advocate doing this by asking how many cars can fit on Manhattan. In my experience, I've seen some people who would handle that sort of question well, and I've seen some really good people who would completely self-destruct given that sort of non-sensical question.

A lot of this depends on the person and the role you're hiring for. If you're hiring a business analyst or designer, for example, it may be important for that person to be able to grasp the context around specific questions or statements, so for them, the "Manhattan" question might be interesting. For a technical role, however, you want out-of-the box thinking with respect to technical problems. Try putting them in a moon-launch scenario, for instance, and throw some failures at them. I once interviewed someone who came into the interview extremely nervous - to the extent he couldn't answer a question without stuttering and breaking up - and as the questions got technically harder, he got calmer and his answers got better and better. If you want a technical hero, this is your guy.

The SDTimes article also talks about team interviewing. Again, I agree with the article -- almost. I think it's important to point out a precursor to the interview that was left out of the article: the phone screen. Before you bring people in to meet the team, it's important that you've had a conversation with the candidate one-on-one.

Done properly, the phone screen accomplishes two things. First, you minimize waste. You clearly do not want someone coming into an interview unless they're going to be in the running for the job. It sucks a lot of time out of your team to do an interview right, and you don't want to waste that time. You will not get a proper sense for this just by reading a resume, though you should be able to rule some people out this way. Remember: when you complete a phone screen and are ready to schedule an on-site interview, you should legitimately feel that the candidate would be a good fit for the job. If you don't really feel this way, don't waste everyone's time with an interview.

The second thing you can accomplish with a phone screen is to give a candidate a sense of who you are and what you're looking for in a hire. You owe this to a candidate, and it will help them orient themselves for the interview. Given a little background, you can tell which candidates are going to take the time to think about how they can fit in your organization. You also get a chance here to let the candidate get to know you. Remember, you're (hopefully) going to ask this person to work for you, so they're going to be interviewing you, too. For these reasons, the phone screen is important enough that you should do them yourself. I've tried pawning this off on team members, and I'm convinced you don't get the right results from this.

The other problem I've got with the Team Interviewing part of the SDTimes article is the little bit about what you do when you don't have a unanimous decision. Bottom line here: you have to have everyone on board. Every team member has full veto power. That's why they're in the process. Note: this isn't the same as saying that any objection raised by any team member will shoot down a candidate - that's why you get everyone together after the interview and talk through their feedback. You can, and should, have people bringing objections into this meeting. If they don't, you need to work on their interview skills. Once you've talked through pros and cons, however, everyone gets a chance to say "no hire". If anyone -- anyone -- says "no", the candidate is history. You've hired all these guys (and hired well, I hope) and you have to trust that they have the best interests of the team at heart.

The last aspect of hiring to consider is skill set and character traits. It's common in our technical environment to get wrapped up in technical skill sets. While it is immensely helpful to know something about the programming languages and environments your team uses, don't lose sight of the fact that our technical environment changes quickly and inexorably day after day, year after year. It may be cliche, but it's true that the only thing that stays the same is change.

Given that change happens, you need to evaluate a candidate's ability to roll with that change and to pick up new tools and technologies. Attitude is an important predictor here. Some people can see technical change as an assault on their self-worth and identity. Trust me, you can't help these people. Some people are quite certain that their way of doing things is the best there can possibly be, bar none. You're not worthy of these people.

Instead, look for the people who are able to focus on an objective and drive toward it using whatever tools are at their disposal, including some they may never have used before. A few years ago, I used to quiz people on resources they used to stay up to date with technical change and to solve tough problems when they encountered them. Today, there's no excuse for instant satisfaction. There are very few problem that don't have answers in Google, for instance. I hired a guy that I completely believe would be capable of working his way through open-heart surgery armed with Google (and maybe a spare patient or two).

In addition to Google-guy, you can look for the silent-but-deadly developer. This is they guy who doesn't make a lot of fuss, but cranks out volumes of code that all works. Note that when I say "silent", I'm not talking about intensely introverted, I'm talking about the guy who knows what the job is and how to get it done, and would just as soon you leave him alone to get it done. This person, in order to be successful, will be able to understand a problem at high and low-levels simultaneously, so he won't be easy to spot, but he's a great asset if you can find him.

Watch out for crisis-boy. This is the guy who creates or magnifies catastrophes so he can swoop in to fix them. This person is characterized by a lot of self-congratulation, technical elitism, and last-minute heroics. His ego is fueled by the adolation he gets when he rescues a release at the last minute. In order to really understand why this is bad, consider how you'd feel about an airline that had pilots that were so good that they could recover from near-disaster after near-disaster. Hats off to the pilots, right, but how about figuring out how they keep getting into near-disaster situations?

When all is said and done, you hopefully will have a group of people who are predisposed to doing the right thing and skilled enough to go do it. The fun part is helping them do their work.

Good luck!

Minimum Process

I've always been a proponent of right-sized process; that is, enough process to do the job, but no more than necessary. Though most development efforts fail on the side of too little process, it's reasonable to be nervous about too much process just for the sake of process. Fortunately, there's an effective minimum that's easy to implement. Read on and make sure you're doing at least the minimum to keep yourself on track.
Over the years, I've seen a surprising number of development efforts that put themselves at unreasonable risk of failure simply by skipping on some simple pieces of infrastructure. Often, this is done in the name of speeding development; as in, "if we skip this bit of process here, we can get this done faster." That makes sense in the same way that skipping an outline will help you get a research paper done more quickly.

In fact, the right amount of process or infrastructure is right because it helps you get the job done as quickly as possible. Some things, like source code control, save time by eliminating those catastrophes that inevitably crop up during the course of a development project. Others, like bug tracking, simply reduce overhead needed to keep track of what's going on. The items I've listed here have made a real difference in my teams' ability to deliver software over the years -- they should be considered minimum requirements if you're building software for internal or external clients.

Source Code Control. This should be pretty obvious, but it's staggering how much software development happens without source code control of any kind. If you're a one-man wrecking crew, you may be able to get away with burning a CD every day, but there are plenty of commercial-quality SCC systems out there that are free for single developers or non-profit development -- check them out. If you're part of a team, this is simply not optional. Pick a system and start using it.

Build Machine. Some may be surprised to see this show up on a list of "must-haves", but it's been a key for me over the years. Simply put, this innoculates you against "it works on my machine". By setting up a build machine that is connected to the team via your SCC system only, you guarantee that you have one and only one system configuration that produces your "official" builds.

Note that there's nothing here that says developers can't do builds on their local machines; on the contrary, that can help boost individual productivity. If your build system is able to handle this, that's fantastic. Under no circumstances, however, can you ever consider a build done anywhere other than your build machine to be considered "real".

A related but separate issue is build frequency. I'm a fan of daily builds, but I've used build machines for weekly or ad-hoc build schedules, and the concept is just as valid in these other settings, too.

Bug Tracking. This can be an excel spreadsheet if you're really compelled to go minimalist, but again, there are so many great options out there that don't cost a thing, that I think you'd be foolish not to set up a "real" system. Use it to track bugs, and be religious about it -- it it's not in the system, it never happened. Don't let this be an excuse to be abusive to customers who don't have access or knowledge to use the system; you may end up entering some bugs for them. Just be sure they're in the system.

You may find that you want to track feature requests, support incidents, or other to-do items in your bug tracking system. Once everyone's in there on a regular basis, this can make a lot of sense, and can take the place of "big process" for things like requirements management and help desk support. Go ahead and exceed the minimum if that makes sense.

Automated Testing. If there's an optional item on the list, this is it. There's often a fair bit of work involved in setting up effective automated testing, but once it's in place, it's a powerful tool. Find some small amount of unit testing to start with and give this a try. You should be able to see results quickly and convince yourself that futher work is worthwhile.

Good luck with these -- I'm sure you'll need to exceed these minimum guidelines for many projects, but if you ever stumble into one where you're not meeting these minimums, get them in place as quickly and as carefully as possible.

Microsoft’s gotta be sandbagging….

Ok - I've got a new theory to explain some of Microsoft's more inexplicable behavior. After all the anti-trust muckety-muck they've been through, they're a little gun-shy about taking over the world all at once, so they're hitting a few short flies to the infield to keep everyone off guard. That's my theory, anyway. It's the only thing I can come up with that would explain why they're not swooping in and simply scooping up market share with a big bucket.
There are three big areas where Microsoft is just whiffing right now, and I can't believe that this isn't abundantly obvious to them.

  1. App server integration
  2. Low-end development tools
  3. Workflow / business rules

Ok, one at a time now. App server integration. I've remarked in the past that someone could make a big dent in the market by integrating .Net support into a recognized J2EE app server. Gotta be one that's already acknowledged in the market. We've got enough app servers out there already, after all. Build .Net support (via Mono) into an App server such that JNDI and app management work similarly no matter what the app was written in.



Speaking of Mono, for Pete's sake, get behind these guys, already. They've just released Mono 1.1.10, and they're starting on .Net 2.0 support. They're funded largely by Novell right now, and they're doing the best they can to keep up, but there obviously are some things falling by the wayside due to lack of funds / bandwidth (Novell had apparently told them they're not going to fund development of VB.Net support in Mono, for example).



So there's this group of developers sitting in the open-source camp growing a list of followers - throw 'em a bone. Make a public announcement endorsing the guys, and toss them a few bills. You kill two birds with one stone: Mono is going to attract developers who would otherwise be using Java or LAMP on a non-Microsoft platform, so you're eroding someone else's market share, plus you get to point to this great open-source showcase the next time someone starts griping that Microsoft is big and mean and closed and anti-competitive.



My final observation on this point is that I've personally experienced the horror of not being able to sell .Net as a development platform simply because it implies platform lock-in. I ended up having to architect in Java for a shrinkwrapped software product simply because I couldn't get over that point. At that time, Mono was very young, and even alternatives like Mainsoft were just beginning to surface. I don't know how many other people out there are falling victim to exactly the same circumstances that got me, but Microsoft could end all that by just coming out and endorsing / supporting something that offers the promise of open platform support. Compete on the basis that Windows is the best place to run your app -- not the only place it can run.



Next point: low-end development tools. First, when I say low-end, what I mean is low learning curve, not inferior. Microsoft once had a pretty broad spectrum of development tools in Visual C++ and Visual Basic. These tools essentially merged with the introduction of VS.Net. Granted, there are different languages to ease adoption from the various camps, but the biggest learning curve in .Net is the framework itself, and that's the same no matter what language you're writing in. The .Net framework in general, and C# in specific are widely acknowledged to be Microsoft's response to Java, and in general, I think that's a good thing. Hit the mark pretty well, if you ask me.



What's missing, though, is the tool support for everybody else. The original concept behind Visual Basic was to enable Windows development for the masses. Though "the masses" turned out to be a subset of developers, this was still an huge score for Microsoft. You've no doubt seen references to the VB developers who feel scorned an abandoned by Microsoft now that they're ending support for VB6. If you ask me, I think an awful lot of the real hurt those people are feeling is not over the death of VB6, but over the death of the original idea behind Visual Basic.



When a group of customers asks for something that appears not to make sense, you've got to look past the points on the surface to understand what's really irking them. In the case of the abandoned VB developers, the thing they really miss is the simplicity and elegance of early VB. There's a hole in Microsoft's product line, and it's not going to be filled merely by giving away VS.Net "Express" editions.



There's growing support for simplified platforms like Ruby-on-Rails -- largely among Java developers, but the appeal for any developer is obvious (here's an excellent example from the point of view of a J2EE developer). Development platform like ROR have the simplicity and productivity of early VB while offering the ability to run on open platforms -- important for an app you may want to host on someone else's server for $9 / month.



I covered the open platform point already, so I'll stick to the simplicity point here. Lots of people have tried to hit the sweet spot where business analyst meets developer. From the analyst side, we've (nominally) seen UML, which missed badly. We've also seen Microsoft try to extend office with Access and Frontpage and VBA with limited success. The original VB tried to his this spot from the development side, and the "express" products are targeted there right now.



Nice tries, all of them, but not quite enough. Current direction calls for Office to keep pounding away with tools like Infopath and Sharepoint, but we need more. There needs to be a real "less is more" product that knows what its limitations are and is ok with that. Maybe it can't be a whole other product, for fear of fragmenting the product lines too badly. Maybe it's something you insert into word doc or an excel sheet like you'd insert a table or a chart (insert new Application...).



All of this transitions nicely into my last point - workflow and business rules. I've already written about my initial reaction to Microsoft Workflow. By targeting Workflow squarely at developers, Microsoft is missing again that confluence of business users and IT groups. Yes, I know that this is just the beginning of a strategy that's supposed to play out as Vista and Office 12 are released. In the mean time, the business user is left wanting.



This will remain the case even after Office 12 if programming languages are the only way to express business rules. Business Rules Engine (BRE) products are poised for growth soon in the same way that Business Process Management (BPM) apps have grown over the last couple years. Among these BREs are products that can express business rules graphically - no coding required. Most of the BRE's out there lack the scope needed to effectively integrate into the enterprise out-of-the-box, making integrators essential to deployment.



If Microsoft could learn from some of these vendors (or possibly snap up one or three), I'd bet they could produce a fully Office-integrated application that a business person could use to produce solutions that were really enabled from front-office to back-office.



The good news for everyone who isn't Microsoft is that as long as they leave these holes unfilled, there's room for other vendors. The part I don't get is why nobody's seen the holes yet.

Basic Image Editing – Highlight a Window

On occasion, I've had to do some real simple image editing to support technical documentation, design docs, powerpoints, and so on. Here's a technique I used to take a desktop-wide screen shot and highlight one window by fading the rest of the desktop to near-grayscale. You could use this same technique to highlight part of an application screen to draw the viewer's eyes to the part of the picture you want them to pay attention to.
(1) Take a screenshot. Alt-prntscrn works as well as anything else, IMO.

(2) Paste into an image editor. I use PhotoImpact, but virtualy anything should do. You could try Gimp or Paint.net (http://www.eecs.wsu.edu/paint.net/index.html) if you want something free.

(3) Make a copy of the image ("highlight").

(4) You should be able to find a "Hue / Saturation" control in whatever you're using. Use that to dial down the saturation to achieve the effect you want. This can be more subtle than going all the way to greyscale if you want.

(5) Take your "highlight" copy and select the window you want to highlight -- you may be able to use an "edge find" tool, though I seldom have good luck w/ this.

(6) Copy the highlight window and paste into the base that you dimmed earlier.

This should get you pretty close. I don't, btw, know of any tools that make this any more automatic than this, but this shouldn't take more than 1-2 mins per screen shot.

From the “You heard it here first” department

If you read Clash of the Titans on this site earlier, you saw my opinion that Microsoft and BEA should get to be closer friends. So I read with obvious interest the announcement that Microsoft and JBoss are forming an alliance.
The MS-JBoss partnership strikes most people as a headscratcher, but on deeper examination, it looks like a pretty shallow marketing deal. No great product innovations seem imminent here.

Watch for the type of integration I predicted before, though. It could come out of the JBoss partnership, or it could yet come from BEA. As I wrote earlier, an independent BEA or JBoss pushing .Net has a unique appeal that wouldn't be matched should Microsoft just snap up one of these vendors.

Nevertheless, every once in a while, you see people ask things like "Who will buy BEA?"

Ok, so no predictions have come true to the letter yet, but if you squint, you can see shapes coming into focus. Keep watching this space....

Microsoft Workflow: Missing the Mark

Last week, Microsoft unveiled Microsoft Workflow Foundation (Google 'microsoft workflow foundation' for lots of press coverage). This product had a chance to really change the landscape of BPM vendors, but it missed its mark.Looking at the press releases, screen shots, and Microsoft's own web page, you can see that MS Workflow bears a strong resemblance to lots of existing BPM products -- including Oracle's BPEL editor for Eclipse. This is a direct result of Microsoft's decision to build Workflow on top of Visual Studio. Microsoft is declaring that Workflow is the domain of the programmer, not the business user.

I understand the argument to do this; I just don't agree with it. It's too easy to fall into the trap of declaring business people incapable of designing and maintaining an integrated workflow. It would have been much harder to find a way to put this power in the hands of a business user, and still maintain the solid technical underpinnings that an enterprise IT department requires.

But that's what's needed.

Microsoft has left the door open. There will be BPM vendors that rush in to fill this hole -- at least until Microsoft realizes their mistake.