Basecamp started out with a somewhat elaborate scheme for deciding whether a given project was active or not. It looked at the activity in the project, such as whether any post had been made within the last 30 days or whether there was uncompleted milestones in the future.
The problems with this policy was plentiful:
What do you do when a project is done? With the old system, you had to carefully wait 30 days (and make sure not to make any additional posts as the counter would then be reset). A project ready for the archives would thus still show up on the dashboard and in the lists, cluttering the activity of the projects that actually were active.
What do you do with a project that's just on hold? It's not unreasonable for active projects to lay dormant for a month or more even though they're still important and you still need access to the information contained within them. With the old system, you had to poke to the system every once in a while to keep it active.
These problems were made worse by the fact that Basecamp is tiered on the number of active projects you have. So with a Basic subscription capable of 10 active projects, you would have to wait around for a done project to go inactive when bordering the limit before you could start the next active project. While that might have triggered a few premature upgrades, I don't believe that customers would be happy in the long term to pay for a tier that they don't really need (don't be evil and all that).
So our solution: Stop being clever about it. Just let the customers decide when a project is either active, on hold, or ready for the archives. This realization of course lead to even Less Software. I was able to do a bunch of what I enjoy most about programming — remove code rendered obsolete by simplifications by a deeper understanding of the domain. And I can tell you that I enjoyed yanking every single one of those methods and callbacks.
This of course goes back to the old Word joke Are you writing a letter? We had the simple answer all along, but refused to realize that we were doing harm in an attempt to do good. Lesson learned. Stop assuming on behalf of a human what cannot be assumed without inconvenience.
Due to word-of-mouth and the recommendations I've been reading across the Internet, I've gotten the impression that 37 Signals were the Kings of Design, to the point where the competition was both envious, copying and worshipping. Web design and development is not a business that I'm a part of, but I have turned to 37's minimalist approach for inspiration more than once, with regards to my personal website.
I haven't tried Basecamp, as I haven't had any proper, project-oriented excuse to do so - but I am bordering on being shocked that the "active/finished" status has been decided by a algorithm instead of user input. I've assumed that every basecamp project would have an "Is This Project Active? Yes/No"-option by design, and the fact that this feature has only been added post-launch has led to me losing some respect for 37 Signals. It's the kind of feature that I consider so blatantly obvious that I'd expect it from any given amateur software solution.
I'm still pretty sure that 37 Signals are miles ahead of the web design competion, though :)
Challenge by Jason Fried on August 19, 6:05
I've assumed that every basecamp project would have an "Is This Project Active? Yes/No"-option by design, and the fact that this feature has only been added post-launch has led to me losing some respect for 37 Signals. It's the kind of feature that I consider so blatantly obvious that I'd expect it from any given amateur software solution.
Well, we felt that one less "thing" that someone had to do was the way to go. So, instead of requiring people to HAVE to change the status of a project, we would automatically change the status if the project went untouched for a certain period of time. It was an elegant solution to start, but usage has evolved and we've evolved with it. That's what being better is all about.
