In the never ending quest to find better tools, I’m torn between two approaches to publishing online: weblogs and wikis. Both tools stroke my ego by making it possible to print my pithy perspective. And both tools appease my laziness, by making it simple to organize my stuff.

Weblogs are good at showing what’s been happening, like what I’ve been thinking and reading. They’re also good at getting the word out about what I write, and letting people know when new articles are available. As an afterthought, weblogs track categories too, which allows my readers to explore veins of stuff I’ve done in the past.

Categories in my weblog, though, don’t seem to be particularly effective. My site statistics show that only a few percent of people ever touch the category-based archives. Most of my traffic is split between people reading what’s new (front page and RSS feeds) and people following links from other sites.

Wikis solve the opposite problem, they organize mountains of information. They’re great for things like software projects and personal notebooks, but not so hot for seeing a snapshot of topics over time.

Both wikis and weblogs solve their own organizational problems well, and both fail at what the other excels at. Weblogs are mini newspapers. Great for short, pointless bits, but a shitpile when it comes to managing large mounds of information. Wikis are books, great for piles of information can be broken into pages, chapters, and topics. The problem is that warped needs both problems solved, without the drawbacks of either tool.

Of the two tools, I’m finding that wikis are the better breed. The name threw me off the first time I heard it, but the approach is incredible: they make it trivial to write about stuff that references other stuff. Good wikis, like MediaWiki, provide a simple markup format, quick ways to reference other material in the wiki, and simple tools to categorize, index, and cross-index it all. It’s like a blank note book waiting to be filled.

But I still like the snapshot effect of the weblog, so I’m dreaming of a way to provide a useful weblog view from my wiki. Or maybe I’ll find a way to include wiki pages from my weblog posts. Or maybe I’ll make my weblogging tool more like a wiki. Now I just have to decide where to put this article …

So you have yourself a software project. Maybe it’s a Free project, a commercial product, or some internal tool. How do you make it better?

Conventional wisdom suggests that you should use your own software as soon as it’s functional; eat your own dog food to gain a first-hand perspective of it’s qualities. The principle encourages change by inflicting software on the people building it. And given the right circumstances it can work.

I was talking to a future Microsoft employee about Microsoft eating their own dog food. In our discussion, I realized that the principle is incomplete: Microsoft, for example, has followed the approach religiously for over a decade, and they still struggle to produce average quality products. I use a lot of Microsoft software. While workable, it’s littered with many points of frustration. This isn’t just my impression either:

You can’t even be mad at them, since they’re only programs. Although, come to think of it, you can be mad at programs; Microsoft Word has inspired me to rage far beyond anything these robots engender. — Roger Ebert (review of ‘I, Robot’)

Microsoft software isn’t improving, and they use it a lot. They’ve grown accustomed to the quality problems, accepting them, and redefining their perception of quality. They’re inbreeding quality.

It is a case of inbalance and skewed perspective. If all you use is your own software, it becomes your new perspective. What are you going to know about alternatives, if you don’t use them in-depth? Artists draw inspiration from works other than their own as it’s a healthy approach to perspective.

You really want to use and get to know many different products, including your own. Contrasting your approaches to others is critical, as is the willingness to question fundimental requirements and assumptions. You need to understand how other products are built, and how they balance usability, scale, and complexity.

Change is difficult too. If you’ve always used one approach, there is a good chance that you (and your teams) will fear, or botch a change to something else. Worse, if you don’t know anything about alternative and historic solutions, it makes it difficult to comprehend the scope and effect of change. A great product doesn’t exist without balance, understanding, and perspective.