Sunday 6/13/2004
Business
When I first came to work at my current long-term contract (scratch that, make that the second time), I immediately set up a wiki to capture and display thinking, planning, and progress on the very large project that I had been given. I had become somewhat enamored of wikis, both in their flexibility and in the excellent things that could be read on some of them (witness the venerable
Portland Pattern Repository
and its associated tangents; delve deep for the good stuff: search on
JavaScript
and poke around from there, for example).
It worked well for me, and later, when Nils came aboard, we used it together to jot down things we would need to know later, lists we didn’t want to forget but knew we would, our current thinking about a controversial topic, development wishlists, etc. We still use it, generally to great effect at the beginning of a project or release cycle, tapering quickly as we get deep into development when most of the decisions and hard work have been taken care of. But it isn’t yet the Tool of Magnificence(tm) that I had hoped for.
Why is that? A few reasons:
- Try as I might, I could never get any of my supervisors to consult it to get a sense of our progress. They were far mor interested in speaking directly with a human, which is understandable.
- The front page of a wiki cries out for significant maintenance and organization, since (for project work) it should lead the reader more or less directly to the expected content.
- A wiki is only as good as you make it. It can wither like a lemon tree subjected to sporadic and capricious watering. (I know of these things.)
- Most sufficiently clean wiki packages have difficulty handling blocks of code, images, and the like. Generally this is seen as a good thing, as the wiki’s job is to smooth the entry and cross-linkage of text, but there it is.
- One could easily spend far too much time refactoring a usefully large wiki.
Never mind the fact that when I first put up the wiki I had to host it on a public server outside the firewall and thus exposed the project to the prying eyes of any Tom, Dick, or Competitor that happened by. This has (long since) been remedied, and I knew better at the time. The wiki was great, but not great enough. Since it was populated solely by my content, it was really only useful to me and people who touched my duties in a direct manner (that sounds dirty).
These days, people are getting into the idea of using blogs and blog-like tools for project management, project notes, etc. Some notable people have even made commercial tools that move strongly in this direction, such as
Basecamp
, a blog/calendar/PM tool from the fine folks at
37Signals
. I haven’t kicked it around yet, but I like the general idea. But!
A blog is great for capturing thoughts in time, including progress reports, notes about interactions, state of thought, milestones, difficulties, etc. A decent search engine leverages that usefulness by allowing you to reach back for something without knowing how far. But it is commonly the case that you’ve got to link this progress somehow to the artifacts produced (such as use cases, layouts, approvals, etc.) as well as somehow get all of the
stuff
related to whatever topic you’ve got your head jammed into in front of you so you can smell it, look it over. A blog is not so good at these things. You can spend days working on a polycategorization scheme to try to get there, but you’ll never have a sufficiently robust yet somehow easy-to-use structure.
Mind mapping software? Who said that? You - there with the smirk - out of the room.
It is becoming more and more plain that some combination of the blog and wiki technologies is in order. If you can safely link that to a repository of files, even better, since another thing every project needs is a single authoritative source of all of the text and images that are produced that aren’t code, all of those aforementioned artifacts. Flow sheets, requirements documents, IA diagrams, mockups, wireframes, blah blah blah. Good stuff, useful stuff, but so many pieces of hay surrounding the needly little scrap of info that you just know is in there, someplace, and needed yesterday.
eRoom? Surely you jest. Have you
used
eRoom? Out with you.
This is all coming up now because of additional work opportunities in the offing, and the relative lack at such locations of any coherent attempt to address any of the above issues. Seriously. So it is left, for the moment, for me to ruminate on. And
Josh
, Swiss Army Knife of developers that he is, to ruminate on in his own sweet way. I’d start with a “work blog,” just a simple self-capture of work dailies, but I wouldn’t be satisfied if I couldn’t somehow get my paper notes in there as well (a significant undertaking).
Ruminate ruminate ruminate. Chew chew chew.