markpasc.org weblog

Frontier/Radio Userland is showing all the signs of a dead software product, having fallen into a classic software engineering trap. As much as I respect Dave Winer in a lot of ways, I think he seriously underestimates the importance of good design and solid code, and seriously overestimates the importance of maintaining bug-for-bug compatibility, esp. in the face of bugs that make some things essentially impossible.

The “Rube Goldberg” feel is very real; add up the effects of haphazard Guest Database implementation (and the resulting addresses like @[“C:\RU\Guest Databases\Me.root”].hello, which are difficult to deal with in a lot of ways), a lot of outliner quirks that make the program difficult for me to use for any serious use, XML encoding and decoding quirks (AFAIK, there’s a double-decode bug still embedded in the kernel-level code for xml.compile, which is impossible to completely hack around), wierd environment stuff like the “root” stuff that just went by, the propensity of the program to crash if you do anything wierd or intensive with the ODB (and you can never reproduce the crashes), copy/paste quirks, and a host of other small problems that I’ve encountered but don’t remember, and it’s hard to get any serious work done in there. Oh, and despite a nice ODB the monolithic code that Userland tends to write is infuriating, and itself contributes to bugs. (And yet for a good long stretch it was still one of the better environments around.)

In fact there’s probably an interesting essay in how outliners can be easily abused when writing code, because one of the biggest cues that your function has grown too large, screen size, is too easily obscured in an outliner environment. IMHO in disciplined hands the benefits outweight the risks, but I digress…

The trap I mention in the first paragraph is the Big Ball of Mud quagmire. There are some solutions to the problem and as the link suggests its not necessarily the unmitigated evil we’d think at first, but it does need to be managed and I’m not convinced I see such management going on. The quote out of that that most reflects what I’m trying to get at is probably this one from the “Sweeping it under the rug” section: It should go without saying that comprehensible, attractive, well-engineered code will be easier to maintain and extend than complicated, convoluted code. However, it takes time and money to overhaul sloppy code. Still, the cost of allowing it to fester and continue to decline should not be underestimated.

Eventually you have to bite the bullet, swallow the costs of fixing code and potentially “breaking” code that depended on those bugs, and make it so you can move on, because eventually the accumulated bugs kill you anyway.

This criticism is not directly intended as an actual value judgement; it is possible that Userland could not have survived the lull it would have taken to fix these problems, as the customers would have perceived that as a lull and may not have waited for the next updates. (Although, interestingly, every time I’ve refactored code, new features that would have been difficult or impossible before the refactor either directly fall out or are trivially implementable, to the point I’m seriously beginning to wonder if this is a reliable effect.) Regardless, the problems are there, and not only are they not going anywhere, they’re stacking. Some serious housecleaning is in order and it will not be easy.

This isn’t armchair quarterbacking; I have in fact undertaken just such a project at work, to clean up and bring better software engineering practices to parts of a 10+ year old code base (same essential age as Frontier in many respects, and it has the distinction that much of which was written by much less skilled programmers then Userland has). It’s not easy, but it can be done incrementally, it can pay off incrementally (it’s not all-or-nothing), and most of all, it can be done. Already it’s paid off in unexpected ways and I’ve only been at it for a few days.

I haven’t heard much from Userland lately on the new features front so I still sort of hope that the current time is being used for exactly this; I can’t prove it but I strongly suspect such things will be necessary for them to survive the next few years. I guess we’ll see.

I think that’s the longest comment anyone has ever left me. =)

I really tried to like Radio. After I switched to MT, I decided I was going to write a review of the product, but every time I tried I discovered it ended up being a litany of complaints. I followed the “If you don’t have anything nice to say” doctrine and canned the post.

All the Radio 8 early adopters’ accounts will have come up for renewal by now. It’d be interesting to know the burn rate.

Yeah, it would be interesting. I know mine has that “Renew Radio…” option in the context menu every time I start it (which is growing less and less often). But then, I was in the beta and didn’t actually pay for it the first time.

I still run it for the aggregator; I need a web-based aggregator because I use it from multiple systems, and the integration with the weblog is nice. Despite the fact I’m not using their hosting, I still paid up when the renewal time came. (Just because I can write my own weblog system doesn’t mean that paying $40 for features to appear spontaneously, instead of my laboriously adding them, doesn’t mean it’s not a winning proposition.)

I guess I don’t have a problem with using “Radio Userland” the aggregator and weblog facility, but I’m pretty much done developing with the internals; I’ve moved to Python and I’m not coming back to RU until it is majorly cleaned up, at least. (Probably never, since I’m going to be seriously involved with my own work.)

The Movable Type bookmarklet is about as much integration as Radio gave, and that’s with the whole web. Radio can automatically post from a feed, but you need software to do that and you can do it with software with MT as well.

And yeah, I’ve run Radio for the aggregator since I switched to Movable Type; only now am I switching to something else for aggregating. That’s why I have to work on this pyblagg thing now. ;) I even stole the theme I’d been using in Radio and Kit’s post form, to build the page with. I’m pretty surprised how easy it was, though big chunks were already done (like the parsing, and nice web fetching).

I still haven’t copied all my YACCS comments over though.