Comment by moe | Hacker News Reader

Comment by moe | Hacker News Reader

Parent Full thread

I'm skeptical that a wiki is still a sensible angle in this day and age.

I've used plenty of them (and like them for tech centric documentation) but let's be honest; they never quite caught on in a business context.

This is most certainly not due to a shortage of implementations (wikimatrix lists 124, no less) nor due to a lack of user-friendlyness (markup-free WYSIWYG ui's are dime a dozen now, from pbwiki to google pages).

I would rather claim that there is simply a fundamental impedance mismatch between the wiki concept and the common workflow in most companies.

Like it or not (disclaimer: I certainly don't), most workflows are still dominated by Word and Excel documents. Those don't mix well with a wiki, in fact they don't mix at all.

Moreover once you enter this battle you'll find yourself not only competing with the friendly closet fileserver ("Just drop it on drive Z:, Sue") and E-Mail ("I'll mail you the new version in a minute") but also with the ilk of MS Sharepoint, Mindtouch and a truckload of other workflow solutions that more or less "work", but most importantly usually allow the users to stick with their beloved MS Office suite.

Anyways, to make a long story short; instead of beating a dead horse yet again, why not look at the ideas that have caught on in the meantime?

Those would be the whole 37signals stuff (basecamp), dropbox, and I guess you also have to count pivotal tracker into that bucket (as much as I despise it personally). What most of these seem to have in common is the "do only one thing and do it well" approach, as opposed to the old "one tool to rule them all" meme.

So, my humble opinion would be that there's still tons of low hanging fruit in the latter market. A wiki on the other hand... Well, perhaps impl #125 will finally part the users from their Excel. But tbh, I wouldn't bet on it. YMMV. ;-)

I'm curious about the issues you have with pivotal tracker. After years of frustration with tools I've found pivotal to be a breath of fresh air. The killer feature is using historical velocity in conjunction with estimates to guestimate when work will be done. This forces managers to see the tradeoffs they are asking for when they ask to squeeze something in. Mainly because of that we found that simply adopting the tool actually improved our agile process. With regards to using it in place of a wiki it depends what information you're looking to track. Pivotal's nature is very feature/time orientated and so may not be suitable for consolidating information. The tags/search functionality might be useful here though. Assuming you maintained the tags this would allow you to aggregate related information retrospectively rather than having to continually consolidate as you do with a wiki.

Well, I've summed up my gripes in other comments previously, it mostly boils down to that I consider the UI an utter abomination.

The shortlist (from top of head): text fields are way too small, I can't edit my own comments after posting, stuff jumps around randomly all the time (due to ajax and because stories move panes when changing status), the whole workflow abstraction is extremely leaky as story-interdependencies cannot be expressed, etc. etc.

For me PT is a toy at best ("Oh look, it updates in realtime when someone makes a change") but nowhere near a serious tool for keeping track of a project.

If you haven't yet then I can only suggest to take a close look at mantisbt. It's not flawless either, but it has 7+ years evolution under its belt and makes an awful lot of sense once you got over the arguably ugly (yet extremely efficient) UI.

I was surprised to hear your objections to the user interface so I took a look at mantisbt. I found it interesting that I hated the interface for probably the reasons that you hate pivotal.

IMO one of the great strengths of pivotal is that there is a single view of the project. While tools such as mantisbt allow you to track lots of information (such as severity and interdependency) I'm not actually interested in this information beyond using it to decide what order work should be done. Pivotal forces you to resolve these factors into an ordering and in doing so provides a much simpler/clearer view of a project.

You could argue that not having this extra information makes reprioritisation harder. In practice I've found that this extra information is often subjective or temporary e.g. how severe an issue is/we really need this feature! I've always found that tracking these opinions is pointless as they change with such frequency that the tool is out of date anyway (ever hear arguments starting with "but you said it was severe two weeks ago"). In the end my experience is that people always know what the important issues are when prioritising, they don't need to keep them in a tool. They also appreciate a simple view of a project which I think pivotal does very well.

Well, with regard to ordering, as said, I have no idea how people bear with pivotal's complete lack of any way to express dependencies. Those are at the heart of any project I've been involved with, as stuff naturally gets delayed and shuffled around all the time. I have yet to find a sensible way to get a comprehensive status-view of a given Goal (consisting of multiple stories) in pivotal.

Take for example this mantis ticket, esp. the "Relationships": http://www.mantisbt.org/bugs/view.php?id=11330

At a glance I can see what state this Goal is in, what the progress is, what it depends on, what it is blocked on (if anything) and who is involved.

With a few plugins mantis will also add fancy progressbars and time estimates. I think there's even a plugin to compute a velocity similar to pivotal, even though I've found that feature amazingly useless in pivotal so far. Perhaps it works better when your tasks are very uniform and your teammates are robots instead of humans. ;-)

As for the higher level ordering (enforcing an ordering on Goals), for that Mantis uses the Roadmap, which can ofcourse also be modified at any time as needed; http://www.mantisbt.org/bugs/roadmap_page.php

Note also that all those extra-fields that are enabled in that mantis installation (Platform, OS etc.) are optional and customizable. In my setups there's usually only one or two, which reduces the UI clutter.

Note also the concise "Issue history" at the bottom which I much prefer over the cumbersome, ajaxified, collapsing/jumping mess in pivotal.

Anyways, to each their own. Different people, different priorities ;-)

Agreed. Providing structure around an existing workflow for a target group is exactly what the doctor ordered... but even that's a tough nut to crack. One of our hopes in exploring existing workflows is to identify both winners and losers around specific use cases. Thanks for the thoughtful response.

The problem with this approach is that there are as many workflows as there are organizations/people?

There are, yes.

But there are lots of common patterns (i.e. email to discuss details with colleagues after a new updated document is published). Supporting each individually would never work but observing and supporting the most common workflows within a group or diverse groups is a great way to create a compelling product imho.

Thanks for the insightful comment. You hit the nail on the head - we're not interested in building another wiki (as you mentioned, we haven't seen one we've liked). We're just trying to think about whether it's possible to solve the problem in a simpler way.

Reply on news.ycombinator.com