CS Migration (When Less Is Actually More)
It was sort of a long, lazy effort, but I believe everything's migrated over to CS 1.0 now on the shared server this place sits on. Here's my net takeaway: it's still just not easy enough, you have to be a motivated 'hobbyist' with these things or you'd never stray very far from the Blogger/TypePad hosted confines.
I was thinking of this after spending more time than I wanted writing nasty migration queries to map migrated CS post ids to their old non-identity .Text values (the migration tools do a good job with the data, but the one I used doesn't try to keep the old post ids consistent... which is a reasonably important consideration lest old links blow up everywhere). Cursors ahoy. And my mind wandered to Basecamp and my new recreational study effort, Rails.
For the uninitiated, Basecamp is clean and easy to use and very hyped in the designer community. It has a fair number of limitations, I seem to come up with a new time I use it. It can't quite do everything I want from something in it's space yet, but it does a lot of what I want and it does that part well. Nonetheless, I still find myself liking the application and rooting for it to keep succeeding.
But contrast Basecamp and how users really seem to warm to it and SharePoint. We've used SharePoint at the last three firms I've worked at to serve as the de facto project space. People use it as little as possible, and with all its rich functionality, it seems to be more tool than most people are willing to absorb. Project sites tend to rot and rarely become the epicenter of a project's communication space. Basecamp projects probably have better results, but then again, this might also be because Basecamp projects are simpler than a large application development effort--this is a sweeping generalization, it would be cool to see what a large project that Basecamp fits perfectly looks like (including the human/team factors).
Anyway, this is purely general/anecdotal, maybe the lesson here is to not start from exponentially more functionality than the bare minimum users require to find something useful. This seems self-evident, but how many times do a set of requirements reflect what people would like to have in a product envisioned as mature vs. a project that was egregiously immature but just barely useful.
Start at the barest of minimum thresholds and execute that set of functionality extremely well--be in the top 10% as far as how you do your well-rehearsed if small repertoire of tricks. Build users by being good not broad, lovable but not complete, and add what's most in demand as you move forward. It's effectively an agile business model or product life cycle,
Which is almost exactly what the guys at 37s have said they're doing a number of times. It's sinking in, but everyone says things like this; it's sinking in from watching them, not just listening to them.
This seems like a more centered way to build software and it is really only viable with iterative/agile processes (and likewise probably works best in hosted application contexts). That said, the typical business challenge I seem to find on the doorstep is orders of magnitude more complicated than what Basecamp automates... to say nothing of truly minimally useful being largely inconceivable in today's for-hire engagement models.
Basecamp is a fitting name in more ways than one, if you could build more applications with this style of bottom up planning and execution, a journey of small incremental pushes upward, I'm guessing the world would have itself a lot more applications people loved.
Hopefully, as I get up to speed on Rails, coming at this problem from the execution side of the equation will confirm that making less > more true is reliably and practically achievable.