Ask HN: Is Basecamp Good? Genuinely curious to understand from people who have used other stuff from Atlassian, Notion etc and successfully made switch to Basecamp. Or vice versa. Basecamp design and tools look very well done but somehow in the past it has not stuck much with me or various teams I have tried it with. Love DHH & Jason on X and their books tho! |
If your project is really big on the other hand, a lot of people are working on it, you need tools to estimate it, and copying it every few days is not an option, you want JIRA, something like it, or at the very least Github Issues.
(I don't know anything about him and haven't heard of him before this post. It at least seems more coherent than most political posts we see online these days.)
Basecamp 1 was nice to use compared to Redmine or excel sheets. It stood out during that era because everything else on the market was terrible.
Around Basecamp 2, competition starting catching up. It still was better than Jira and plain GitHub issues but we preferred the simplicity of Trello or the more powerful Wrike depending on the team.
By the time of Basecamp 3, we felt there was little need to use it unless you were a fan of 37 Signals. GitHub Projects (despite its flaws) was good enough for personal projects, and work preferred something else more full featured. Nowadays we use Linear for both work and personal projects. Also, DHH was always controversial but he became more so around the time of Basecamp 3 so it was definitely a huge minus.
Basecamp is meant to go along with the "Shape Up" philosophy (https://basecamp.com/shapeup), an alternative to sprint based or waterfall development. But I find both to be pretty confusing and ineffective, especially at juggling the inevitable real-time demands of customer-facing software development.
In Basecamp the software, the company I work for has several projects, each containing several overlaps of the same pool of employees, as in every person is a part of multiple projects. Each project has its own kanban board, forum, and live chat. Each six week cycle also gets its own set of all those things. That means I spend way too much time playing "Wait, where was that one ticket again? Was it in project A's kanban or project B's chat or the archived cycle's discussion board?"
The search is terrible. The UI is bad and doesn't support basic things like code formatting or pasting URLs. The history of "what did I look at recently" is poor. The notifications system is buggy and doesn't work very well. There is no date-based snooze or an easy to see timeline of anything relevant to me. I spend more time fighting the software than using it. I would not choose this for any project of my own.
Then there's the Shape Up methodology, which I think tries to shield developers from the both the needless rituals of Agile (which it succeeds at) and also from outside customer-originated interruptions like bugs and feature requests (which it utterly fails at).
Together, I can see how this methodology and software might work for managing very simple projects, but I find that it breaks down with the slightest bit of real world interference.
Urgent bugs cannot neatly fit into a planning cycle, and so either has to just exist outside of it, or else has to wait until the end of the 6-week cycle's cooldown period. In reality this means we often waste time debating when to address bugs and whether to postpone them until the next cycle. There is no formal system for triage, so it's just kinda a gut feel based on limited information.
It's even worse for feature requests. By design there is no backlog. Team members pitch their ideas at the start of a cycle, kinda guess how much time they would like to spend on it (their "appetite" for it), and then try to constrain it within that time frame, "shaping" it into an actual ticket. Then leaders have the ultimate say of which tickets make it into the cycle to be worked on. I find this system to be both simplistic and unreliable, really just being a bunch of guesswork that yes, discourages scope creep, but also makes for some pretty inflexible development/modification of UX issues that are found during development. What it saves in estimation time, it accrues as tech debt for a later cycle. And because there is no backlog, both discovered issues and customer feature requests that aren't picked for implementation don't have anywhere to live. They just... disappear. I think the theory is that popular enough ideas will eventually organically resurface as a pitch. In reality customers often just get ignored and have no transparency into planned work. There is no roadmap for product development, just vague guesses every month and a half.
To be fair, I don't like Jira and Agile either. Whereas Basecamp is too barebones and unrealistic to be useful, Agile and Jira are too dogmatic and emphasize rigid planning and ritualistic bureaucracy that sucks all the joy out of coding.
Maybe Basecamp pleases developers because it lowers stress (at the expense of customers). Agile pleases managers because it lets them use devs as factory line workers, minimizing their agency and increasing their reliability. It is terrible for developer experience. But neither, I think, does a good job at providing customer focused development.
Very strictly IMHO: What has worked best for me and the small teams I've been on is just a basic kanban board that realistically mirrors what people are working on, with reasonable but not super detailed estimates of time or difficulty. Something that makes it easy to see that Joe is working on a very hard feature, whereas Sarah has a bunch of small ones. If a bug report comes in, whoever is on triage duty that week looks it over and provides an estimation. Probably Sarah ends up taking it because her work is more modular, and she then updates the kanban accordingly to show that she's taken that new bug, and some other planned work is now postponed because of it. I think that sort of system is more able to mirror a realistic development situation where you can't really just focus on long term work and pretend that outside influences don't exist. Various systems always try to shield developers from those outside influences, but I find it's better to just accept it and transparently say "OK, we'll squeeze this in, but that means this other thing will be delayed." It's not a rigid process, just a basic organizational system that can be flexible and modified as needed to suit the team's needs. Don't overcomplicate the process, just document the tradeoffs you're making.
Again, all of the above is strictly IMHO, just my opinion as an IC dev who's worked with several different teams and management styles.
Does Basecamp force everything to be 6 week projects? I would think it should be configurable, I can't imagine every single customer of theirs is ritually following the same exact process outlined in Shape Up. From reading their books, their approach is more about what works for them and sharing that in case it might also work for others and that there are other ways to think about doing work. I wouldn't take anyone's process book as the holy grail that must be followed to the letter. It sounds like your management has done that though and usually that will not work out no matter what process or tool is being used.
Backlogs are a lie. Having a giant list of things people wanted to do at one point but they never saw the light of day isn't super helpful for software development. It is a good way to appease people by telling them you're tracking it, might as well be in the waste bin though. If you capture a feature request and put it in the backlog, then look at it 3 or 6 months later, its very possible that feature is no longer relevant, the software underlying that feature has already changed with other work, etc. So capturing a lot of detail on something that is a "someday, maybe" type of request is pointless. Maybe a wiki doc of ideas is better.
Bugs are a different story - customer issues/bugs reported should be captured if they are relevant. Urgent critical bugs should be able to be created in any work tracking system and be worked, again this smells more like the people organizing the work and defining your processes have things kinda borked up.
I think that's fair, but to some extent, the tooling will naturally lend itself towards some process or another, and thereby encourage (not force) people to do things a certain way. It's possible to use Basecamp with only one project and the Kanban board, for example, and not use the chat or forum features. But that's just not really how it's made to work.
It is more the combination of Basecamp + Shape Up that I don't like, especially the idea that the "backlog is a lie". Honestly, that's one of the very few things I miss about Agile. Not so much the grooming sessions, the t-shirt sizes, or any of that crap, but just having a single, organized place where you can put ideas in cold storage and refer back to them time and time again.
Even with an ungroomed backlog, it's very easy to say "this feature request/bug is very similar to ticket 12345; let's merge them". And then over time it naturally accumulates more and more relevance and hopefully eventually becomes worth doing, and you can immediately justify that from all the connected tickets and concerns. It isn't so much the level of detail that's useful, but having a single reference acting as a single source of truth for a given issue.
Without a backlog, using just a document (or in our case, often nothing at all), the same ideas keep popping up, but there is nothing to refer them against. A single bullet point in some ideas doc isn't easy to cross-reference by hyperlink, either for other devs, customers, or onboarding new employees. You go from 'we have a source of truth with too much junk in it" to "now there's no source of truth anymore, just a bunch of vague ideas floating around in various documents and in people's heads". IMHO that is not an upgrade, not even a sidegrade, just a plain downgrade. It's exchanging "a large amount of tickets organized in a single place" (which is difficult to get through, yes) for "a large amount of ideas without any organization at all" (which is even harder to work with).
The lack of a backlog doesn't magically make lower-priority issues disappear. It just makes them harder to track over time, such that you end up having to reexamine them and re-triage them and re-evaluate and re-plan them every time the same thing comes up. With a single ticket to reference in a backlog, each incremental update takes a few minutes (oh, this is what's changed since 6 mos ago). Ideally you'd update the original description too (I always do that, but granted not everyone would). If you don't even have that ticket to reference, you're just starting from scratch every time and it's frankly exhausting.
The backlog doesn't have to be something super complex and time-consuming. It can just be one column in the Kanban. (I love Airtable and would love to try Linear for this). Maybe even a wiki, as you suggested, although I think that'd just become yet another source of truth vs an integrated backlog... the way that Jira and Confluence already often fight each other for dominance.
-----
That said, if you (or someone you know) HAS had positive experiences working with Basecamp & Shape Up using some different kinds of organization... I'd love to hear their thoughts! If there's anything I can suggest to my org to make things easier to work with, it's worth a shot.
(And FWIW, I don't know this for sure, but I think many of the other devs on my team DO like Basecamp. I may just be an outlier... haven't surveyed them. Maybe just how my brain works? I dunno.)
Sorry I didn't say this earlier, but I think the other devs on my team do like Basecamp (or at least haven't complained about it?). They've been using it for even longer than me, since before I joined, and I don't really hear any issues about it.
Maybe I'm just super picky or old-fashioned, I dunno.