November 10, 2003
@ 03:29 AM
Comments [7]
The Difference Between Amateur and Professional Software Development

Miguel De Icaza recently wrote

To make Linux a viable platform for mainstream desktop use our community needs to realize the importance of these third-party vendors and not alienate them. Having a stable API, and a stable ABI is very important for this reason. GNOME has learned this lesson and has strict commitments on ABI/API stability (thanks to our friends at Sun that pushed for this) and the XFree folks deserve the credit for making ABI compatibility across operating systems a reality for their drivers. Two good steps in the right direction.

This highlights one of the primary differences between amateur and professional software development. To professional software developers words like "backwards compatibility" and "no breaking changes" are words to live by regardless of how painful this can be at times, to amateur software developers they are the equivalent of four letter words that should be ignored in the quest to building something "faster, better and cheaper" than the rest.

 

An example of this just hit me in RSS Bandit development. I recently released RSS Bandit v1.2.0.42 which added

The ability to store and retrieve feed list from remote locations such as a dasBlog blog, an FTP server or a network file share. This enables users utilizing RSS aggregators on multiple machines to synchronize their feed list from a single point. This feature has been called a subscription harmonizer by some.

Around the time I shipped this release a new version of dasBlog (which is managed by Clemens Vasters) shipped and removed the XML Web Service end points that RSS Bandit was dependent upon for this feature. To see the difference you can compare the ConfigEditingService.asmx from my weblog to the ConfigEditingService.asmx on Torsten's weblog. Note that they are almost completely different. In the space of one release, dasBlog broke a feature in RSS Bandit and any other client that was written to target those end points.

Behavior like this is the bane of the Open Source world that Miguel decried. It's always so easy to change the source code and tell people to download the latest bits that few ever think of the churn they cause by indiscrimnately breaking applications, after all users can always download the newest bits or tweak the code themselves in the worst case.

Instead of finishing up the perf improvements I had in mind for RSS Bandit and working on perf I know have to figure out how to support both dasBlog APIs in a seemless manner without placing the burden on end users. You'll note that both my blog and Torsten's state that they are running dasBlog v1.3.3266.0 even though they expose different XML web service end points which means I can't even expect the user to be able to tell what version of dasBlog they are running with any accuracy.

What a waste of a Sunday evening...


 

Categories: RSS Bandit

« Joe Gregorio on LongHorn vs. the Light o... | Home | Jazzy Belle  »
Monday, 10 November 2003 06:32:34 (GMT Standard Time, UTC+00:00)
Torsten's site is running version 1.4. The reason it says 1.3 is something I haven't been able to track down but it happened to me last week. I had to rebuild the site from the sources because the assemblhy files didn't reflect the new version. I suspect that Torsten didn't update his site using the .msi installer for the 1.4 version but I'm not sure. There was a small window when 1.4 was released that the source tree was a bit messed up.

You'd have to ask Clemens, but my understanding is that he changed the web services cause of the security implications of exposing the files themselves. If that's the cause I think it's acceptable.

Rather than tying to a specific endpoint, it's probably best to wait till there is a common way to do RSS harmonization as you say and deprecate RSS Bandit's support for a specific dasBlog version.
Omar Shahine
Monday, 10 November 2003 06:58:37 (GMT Standard Time, UTC+00:00)
>Rather than tying to a specific endpoint, it's probably best to wait till there is a common way to do RSS harmonization as you say and deprecate RSS Bandit's support for a specific dasBlog version.

Really? And who's going to come up with this if I may ask? How exactly am I supposed to be able to tell when this incident has occured, after all a number of people have already proposed solutions including Dave Winer.

You're right that I should take the feed harmonization functionality related to dasBlog out of the next version of RSS Bandit. It was dumb of me to do this when I didn't control the code for the XML web service end point (i.e. dasBlog) combined with the lack of standards in this space.

I won't make such a mistake again. It looks like I have to have a private fork of dasBlog where I can add such features without worrying about what else will be broken when next the project upgrades. Unfortunately, this also means I'll keep such features out of RSS Bandit, until sanity exists in the world of weblog APIs which probably won't be happening anytime soon given that the best there is to offer in this space is the ATOM APIs and so far I haven't been particularly enamored with what I've seen coming out of there.
Dare Obasanjo
Monday, 10 November 2003 23:02:47 (GMT Standard Time, UTC+00:00)
For argument's sake, how about you come up with a mechanism? I wonder what would happen if you and Luke Hutteman just agreed on shared meaning, etc. for feed harmonization? I'd guess future versions of dasBlog and many other engines would support the ahem *standard*.
gerrard
Tuesday, 11 November 2003 09:06:08 (GMT Standard Time, UTC+00:00)
Afaik the version displayed for dasBlog is taken from the newtelligence.DasBlog.Web.Services.dll. But for the frontend rendering it should use the main assembly version to display (think it is newtelligence.DasBlog.Runtime.dll). If the webservices interface changes significant (breaking), it should be provided as a new assembly (new name with major/minor version) / new service name combination (e.g. Editing.Service.1.4.asmx or such) and the old one should exists as long as there is any reference software out in the wild that use it. Public webservice interfaces are "world" contracts!
gerrard: we already discuss such things on a private invent only mailing list, Luke is yet a member.
torsten.rendelmann@gmx.net (TorstenR)
Tuesday, 11 November 2003 15:05:10 (GMT Standard Time, UTC+00:00)
The main reason why this happened was that the Web service that I yanked is plainly an open door to the siteConfig directory and should have never been there in the first place. dasBlog inherited that as a BlogX legacy.

What this illustrates is not amateurish vs. professional behavior, but rather that I am not making any promises above backwards compatibility to anybody anonymous out there.

If someone uses the endpoint my software exposes, I expect them to negotiate a "handshake SLA" (means: write me email) so that I know what I need to keep track of and can work with them as I add features to the software. Contract isn't only technical.
Clemens Vasters
Tuesday, 11 November 2003 15:55:03 (GMT Standard Time, UTC+00:00)
Clemens,
There are several things wrong with your statement but I'll just pick up on two.

a.) Sending you an email works if you're working on an application used in a local network by a limited set of users. On the other hand, it is a ludicrous requirement when writing software used on a global network such as the World Wide Web. Imagine what would happen if one had to contact the authors of Apache, IIS or BIND before writing any internet software that used the services they exposed.

b.) If the interface is a security flaw, then the correct answer is to deprecate it or fix the flaw not remove it completely. At least if the end point was there but sent back an error message when invoked users could figure out what was wrong as opposed to the nasty exceptions that occur because the remote method is nonexistent.

If anything your post confirms that in terms of shipping working software on a global stage what you are doing is amatuerish.
Dare Obasanjo
Monday, 17 November 2003 07:00:49 (GMT Standard Time, UTC+00:00)
Whoah, I wonder if there was a need for the overly arrogant/hostile tone there Dare. Ironically your own software needs quite alot of work too you know. ;-)
senkwe chanda
Comments are closed.