brainsnorkel.com

Here is the story of the resolution of my iPod troubles.

Wish me good luck. I don’t want to have to write an unhappy eBayer story.

Most organizations wake up one day and wonder how much more competitive they would be if they never wrote the same code twice. Many organizations undertake significant organizational changes to implement their new found software reuse religion. Generally, reuse initiatives like these are enthusiastically evangelised, resisted by staff, provide dubious economic benefit when they’re in operation, and take years of investment before they are renamed according to the fashion of the day and re-launched.

At the moment web services (WS) and service oriented architecture (SOA) define the vocabulary of software reuse. In previous years it was object models (distributed and plain-ol’), product line engineering (PLE) or component-oriented architecture leading the charge to re-usability nirvana. My software reuse strategy isn’t an interface definition language or a step-by-step methodology. It is a policy suggestion.

I think the easiest and most effective way to achieve effective software reuse for any organization is to institute this policy:

Every software project must publish all of its development artifacts — code, test, requirements, help, training, bug reports and design information — such that any developer in the organization can search and view any development artifact or identify and contact the people working on the project without restriction. For bonus marks, we will standardise on a configuration management, bug and task tracking, development and documentation environment that makes looking at any other project’s artifacts as close to zero-cost as possible.

This may not be a revelation for some organizations. Some developers already enjoy unfettered access to their colleagues’ project files and can search across the entire organizations’ software assets for code, design and knowledge they can make use of. The tendency for large organizations is to Balkanize and tool up in such a way as code and design becomes invisible outside a project. I’m advocating that no matter what the political structure — make sure development environments present no barrier to searching and copying.

I think too much is made of the value of generating reusable software that is packaged in nice, neat, black boxes lined with soft archetype-affirming design documentation, and set to rest in a software asset mausoleum. Standardised look and feel and avoiding embarrassing contradictions in different software produced by the same organization are just some good reasons to formalise some reuse rules and methodologies, but the way to start down that road is to make sure there is a culture of cooperation and sharing. If you are a CTO looking to implement change to foster software reuse and you can’t see and search all of the software you’re responsible for, I doubt your reuse initiative is going to be more than a PR exercise anyway.

While I think there is merit in approaches advocated in many texts,I think that the strategy that is most likely to succeed is the one that does not require more investment than an important and influential person writing down that from now on no project shall have code or any other artifact that is inaccessible to any other developer in the organization. All project artifacts should be available to be indexed and searched by the organizations’ chosen (preferably competent) search engine.

The benefit of this policy is that reuse will occur. Developers like to branch and merge more than they like to use half-thought-out libraries on a different schedule full of set-in-concrete code designed by people that never thought your specific problem would be the one they needed to solve. Fertile open source projects like Linux are surrounded by mini projects that branch from the “main base” and contribute back the benefits in a time-frame that suits the main and branched bases, and opens up opportunities for future branched projects. With an open internal development environment developers can find and talk to each other, search and review the available code and design, copy what they need, share experiences, and avoid unnecessary rework. All of this is possible without any explicit software reuse initiative.

The drawbacks? A rogue developer will be able to release all of your organizations’ code (and not just those projects she was working on) to the known universe when things go sour for you and her. So sue Sue.

According to the signature image at the NASA Goddard Space Flight Center’s software reuse site “It should be as easy to find a good quality reusable software asset as it is to find a book on the Internet.”

John Udell cites an InfoWorld Programming Survey from 2003, where the biggest obstacles to software reuse perceived among developers were:

1. “Effort required to design software for reuse” — 29%,
2. “Lack of awareness of which software is available to reuse” — 28%,
3. “Effort required to learn and effectively apply software available for reuse” — 21%,
4. “Programmer disinclination to package software for reuse” — 10%, and
5. “Effort required to package software for reuse” — 7%
6. “Other” — 5%

Clearly an open internal development environment is applicable to four of the five points here. Perhaps these respondents already have completely open work environments and were looking beyond sharing and cooperation for the perfect reuse technologies.

If not? Perhaps making software available for reuse that cost nothing to design for reuse will help. Perhaps making all software easily searchable and available for reuse at no cost will help. Perhaps never asking programmers to package software for reuse will help.

Perhaps.

This is a scan of the inside cover art for Lucy Cousins’ L’Arche de Noé (Noah’s Ark, in French!) showing pairs of animals walking two by two into the ark to commence their free 40 day P&O “procreate or perish” cruise.

It’s obvious from this picture that today’s peafowl are clones.

The recent arrest of several members of the Seas of David cult, alleged to have been plotting to do something to the Sears Tower in Chicago, was widely reported and then widely lampooned. Initially, I thought it might have been unfair to make fun of it — these sound like seriously deranged people — but (via TPM Muckraker) the evidence is genuine comedy gold.

That’s not to say that they didn’t talk up their destructive ambitions. One of them even “made reference to taking over the world,” according to the FBI agent on the case. [...] it sounds like the group’s leader, Narseal Batiste, went down to his local 7-11 to “obtain financial and military support.”

Nonetheless, this group provide a valuable commodity: terrorism infotainment.

A long time ago a friend, my wife, and I attended a cinema for the Sydney opening of “As good as it gets” — a romantic comedy featuring Jack Nicholson as a grumpy compulsive-obsessive author and Helen Hunt as the other necessary ingredient in a romantic comedy. Ironically our seats were in front of two women who seemed unable to follow the plot because they were compulsive-obsessive about talking to each other about everything that happened in the movie.

After one too many “Oh I love that dog so much!” and “I missed that. What did she say?” my friend turned to the women and shouted “Have you ever had an unarticulated thought?”

They moved away.

There are people, particularly in the business world, who can not let any email go unacknowledged.

You can recognise them when you’re down to the sub-sentence part of your email conversation. They send you an email saying “I’d be interested in seeing that whenever it’s ready.” You send back an email that says “I’ll probably have a draft ready for you this afternoon,” and declare the conversation deceased.

Then they send you back an “OK.”

Is it protocol for me to send back a “Roger?”

What happens when two of these people send each other an email? Is the Internet in danger?

“Freedbacking Bloglines” — that’s the slightly mangled phrase that users of Bloglines are invited to use to provide feedback on the Bloglines service to the Ask Bloglines team through their blogs. Hopefully, I just joined the ranks of Bloglines freedbackers.

Julian has already been freeding backing his commentsing. That post has made me think critically about Bloglines for the first time since Google Reader was introduced.

Why I use Bloglines

I was introduced to Bloglines by Alastair of Girtby.net as a practical way of reading blogs. The features that originally sold me on Bloglines were:

1. Web-centralized blog reading
2. Email subscriptions

These days it’s all #1, and none of #2.

Using Bloglines

I only use the Bloglines blog reading and feed subscription interfaces.

I have “clipped” things before, but that has been a write-only interface for me — I haven’t gone back to retrieve the clipped items.

I have a lot of subscriptions. Most of my subscriptions are rarely read. I arrange my subscriptions into folders with contradictory categorization strategies.

For a start I have a main “blogroll” folder, which is where most of my frequently accessed feed subscriptions reside.

I have a “politics and news” folder, a “software” folder, and some other finer subject areas. I also have a folder for “mid-traffic” which is a kind of infrequently read, esoteric blog bin. When I get annoyed at a blog, blogger, or just begin to wonder why I subscribe to something - I move the subscription to the “rarely used” folder. From here I occasionally delete subscriptions when I get the time and the motivation.

To overcome an edit view problems I have a “moveme” folder. This is a way of getting around what I think is a UI shortfall in the edit function. I have long lists of blogs in some folders, and dragging subscriptions into other folders is tricky - as holding a subscription on your mouse and finding the sweet spot on the browser window where the text will start to scroll is a bit of a test of agility and patience. I just close all of the folders, and put the “moveme” folder above or below the folder I’m cleaning up, and then open it so that I can drag right into the “moveme” folder without having to scroll. When done’ I move the “moveme” folder next to the various folders where I need to move subscriptions and make the changes from there.

The left frame “collapse” bar/button caught me out a couple of times until I registered what it was. I understand the need for such functionality, but accidentally clicking a non-obvious and unconventional user interface component must frustrate more than just me. How about a button in the right side to hide/show the left frame?

A surface-level comparison with Google Reader

I have tried Google Reader briefly and that’s all I can really compare with. Google reader doesn’t optimise its use of screen space as well as Bloglines. Google reader is a slick looking interface with smooth scrolling, nice call-outs and a the trademark Google preference for labeling over hierarchies. Bloglines is still a “tree plus content” sold-school frames web application, but it’s arranged well for presenting large volumes of information in a readable way.

Google Reader seems to emphasise three modes of reading:

1. All new posts
2. Individual blogs
3. New posts by label

The Google Reader user interface wastes more potentially useful screen real estate than the bloglines, and it is more responsive. I would guess that this makes it more approachable for new users with fewer blogs, but more intimidating for users who bring a large volume of source blogs looking for a new reader.

Thinking about the method I use to organize my subscriptions was a kind of a revelation for me about the organizing emphasis of Bloglines and Google Reader described in the comparison below.

If you look above at my sample Bloglines folders, a tag/label system is probably a better fit to my categorization methods than Bloglines’ faux folder hierarchy. The folder system forces the user to make a single categorization decision about a feed. A personal tagging or labeling system allows me to organize based on multiple different, even contradictory, categorizations. I can tag for importance, theme, writing style or other systems without having to duplicate the feed itself.

Trying to reproduce this with Bloglines’ folders is difficult as Bloglines will stop you from subscribing to the same feed twice in different parts of your subscription list. A tag-based approach would make a tree plus document view hard to maintain.

Things I’d like to see

• Update diffs and post history. I guess that maintaining state for each new post is potentially unfeasible, but this would be useful for more than voyeuristic purposes.
• When searching or subscribing or reading, I’d like to see a traffic history for each feed. Something like the number of posts in the last day, week, month, quarter, year would help me know if I’m subscribing to a defunct feed, or a fresh one.
• Defunct feed notification. Some method of putting a change of address sign up in Bloglines for old feeds would be very useful. A difficult problem, but a lot of sites I’ve seen move spend some time setting up, migrating, and generally changing their feeds.
• Sort by past reading frequency. A better metric to sort on might be average time between post and read, rather than frequency. I’d rather a machine tell me my reading preferences than fathom my own.

Do I like Bloglines?

What I like about Bloglines is that it’s very good for showing a lot of information at once and it behaves in a predictable way. Bloglines is reliable, available and free. It’s like my current run-around car. It’s 18 years old and has a couple of niggling problems. I can’t complain about it because it’s the most reliable car I have ever owned — but I wish it was newer-looking.