Infovark

Prior to starting infovark, I read everything I could get my hands on regarding the Web 2.0 phenomenon. Even though I felt immersed in the trend already, I wanted to make sure I understood what other people were reading about it. I also wanted to make sure that I was hearing directly from the primary sources, rather than indirectly through blogs or reviews.

I recently loaned our principal investor several of those books. After putting together the reading list, it occurred to me that I ought to post it to our blog as well. I plan for this to be the first part of an irregular series. To start us off, we have two essential books: The Tipping Point by Malcolm Gladwell and Chris Anderson’s The Long Tail.

Feeling a Bit Tipsy

The Tipping Point describes a contagious situation where a system rapidly changes to a new state. The tipping point can be a “didn’t see that coming” moment, when something finally achieves critical mass and explodes onto the scene. Whether it’s a sleeper movie that suddenly becomes the film of the year, or a previously obscure product that’s now a household name, the Tipping Point describes how that dynamic transition occurs. It’s the classic snowball effect: Each flake, on its own, adds an insignificant amount of mass to the rolling ball. Over time however, those changes can compound into an unstoppable avalanche.

Figure 1: The Tipping Point

The Tipping Point is relevant to Enterprise 2.0 in two ways. First, obviously, is that software companies like infovark want to create a tipping point situation in the adoption of our products. But Gladwell’s book is a description of the phenomenon, not an instruction manual.

The second, more important reason, is that systems that gather, store and search data often experience network effects. Most Enterprise 2.0 systems fit this category, and ours is no exception. Our products need to scale rapidly so that we can harness these effects to return meaningful, relevant results. The crucial trick for getting the adoption rates we want is our ability to employ statistical tricks (and a few smart guesses) to bring that tipping point moment — the moment when someone says, “Wow, this thing is reading my mind!” — as close as possible to the out-of-the-box experience.

…And Pussycats

The second graph-based book, the Long Tail, describes a major shift in the way retailers think about selling their goods. For the last 50 years, product manufacturers have focused on the hits — those few products that achieve mass-market success. In today’s Internet economy, the cost of sales and inventory are dramatically lower. Retailers don’t need to be as choosy about their stock, opening up a large space for niche products to flourish. Taken as a whole, there can be as much money in niche products — in the long tail — as in selling mass market goods. Companies that have figured this out can derived tremendous value from serving these previously under-served consumers.

Figure 2: The Long Tail

The catch is in the phrase “taken as a whole.” To get the benefits of The Long Tail, you have to have a meaningful and interesting way of aggregating the preferences of many, many niche markets. And in this case, the market for information is little different than the market for products. Wikipedia succeeds as an aggregator of information by trading authoritativeness (scholarly writing and professional editing) for an unmatched breadth of articles contributed by the general public. You won’t find many articles related to animated television series in a typical encyclopedia, but you can find details about Josie and the Pussycats on Wikipedia, including their signature lyric: “Long Tails… and Ears for Hats!”

The Long Tail also holds lessons for us. Creating enterprise portals, automated workflow systems, and other broad-brush systems is an Enterprise 1.0 approach. Enterprise 2.0 systems must recognize that organizations are composed of teams of specialists. Each team and each individual will have a different view of the organization, and each is responsible for making different contributions to the collective effort. An Enterprise 2.0 approach must tap the Long Tail of corporate knowledge and expertise and deliver custom-tailored results.

(P.S. Thanks to Brian Shaler, whose CrappyGraphs.com helped illustrate this review.)

We’ve posted a luscious — dare we say lickable? — update to the look and feel of the infovark website. Thanks for all the help, rustybones!

Among the many changes Rhys made:

• The page content is centered in the browser window
• The site now uses more of the infovark color palette
• There’s an archives section to the right sidebar so you can see older posts
• The article tagline now tells you who wrote the post and when
• The author’s name and article categories are clickable, so you can see other things in that topic or by that author

Tell us what you think: Leave a comment.

Hi. I’m Dean, and I was a maintenance programmer.

I’ve just spent the last two days refactoring the infovark storage and retrieval API. It wasn’t that anything was broken, exactly, it was just that it was… messy. There are a lot of things I should have been working on instead, but I couldn’t resist tidying up the object model a bit. It’s a weakness of mine.

You see, “maintenance programmer” is generally considered a pejorative label in the software development industry. Programmers that do maintenance — minor bug fixes, performance improvements, functionality tweaks — are generally on the lowest rung of the development team.

That’s how I got my start in software. My first coding jobs were technical support and troubleshooting gigs. You can ask anyone who’s worked with me on a development project, and they’ll tell you I’m fastidious — some might say fussy — about the structure of my code. And, truth be told, I’m picky about everyone else’s code as well. Since my first experiences with programming were maintaining large codebases written by other people, with no specifications or even a user manual to go by, I’ve developed certain habits of mind.

No respect?

If great hackers are the poets of the software world, then maintenance programmers are the copyeditors. Great hackers produce elegant code. Their deeds are legend in the computer science community, and some have passed into history. Some are so good they’ve been celebrated in free verse. Their code soars in cathedrals of light, pure in its mathematical beauty.

By contrast, the code churned out by the maintenance programmer is solid, workmanlike, and perhaps unimaginative. But it works and will continue to work. There won’t be any odes sung to the maintenance programmer, but at least a few respected developers out there, like Eric Sink and Jeff Atwood, have spoken up for us. There’s even How to Write Unmaintainable Code, a humorous treatise on the many ways to drive a maintenance programmer crazy — and a tribute to all of us that have suffered at the hands of sloppy development techniques.

So we’re beginning to get some respect. And I’m proud of the work I do. I realize that being a stickler about naming variables properly or commenting logical branches only slows down development. But I take comfort in knowing that my code will stand up to some abuse out there in the real world.

Maintenance programmers of the world, unite!

Do you think you might be a maintenance programmer, too? Here are the seven warning signs:

1. You feel a sense of accomplishment after refactoring.
2. You have more than one book of design patterns on your bookshelf.
3. You think that program files should contain more comments than code.
4. You introduce coding standards for any project consisting of more than one person.
5. You don’t trust the compiler and you don’t trust the unit tests.
6. You actually like having code reviews.
7. You know that no program is ever truly “done”.

Sound familiar? If you get the same feeling of delight at sorting out spaghetti code as you did reading Eats, Shoots, and Leaves, you might be a Maintenance Programmer. There’s good news for you, however: You’ll always have a job to do. Because no matter what happens in the computing world, there will always be code in need of a rewrite.

Jim McGee posted a list of essential Enterprise 2.0 articles to the FastForward blog. I’ve read many of them before but found a few items worth looking at again, as well as a few gems I’d missed. I’ve bookmarked it for future reference.

I’d also like to add a few other articles to the list. The first two have to do with managing collections of information. Information is the raw material knowledge workers process into insights, analysis, and innovation. In today’s environment, when there’s more information available than ever before, it’s worth spending some time thinking about how we collect and manage all that data.

• Metacrap — Cory Doctorow. The definitive rant against human-driven metadata classification systems. No organizational system can ever be complete, nor will everyone agree to use the same one, because we all have different perspectives and different goals.
• Ontology is Overrated — Clay Shirky. A classic discussion of the reasons for a shift from formal classification systems to more probabilistic approach. Authored in 2005, just as the term folksonomy gained wide acceptance.

The last link has to do with social networks and is perhaps more relevant today, post-Facebook, than at the time it was authored in 2003.

• A Group is its Own Worst Enemy — Clay Shirky. An article that explains why social networks are different from physical networks: In social networks of a certain size, there are diminishing returns to scale.

I’m sure I’ll think of more, but these are the most obvious and most readily available articles missing from Jim’s list. Happy reading!