Ask HN: Is Basecamp Good?

For small simple projects it is OK but for small simple projects I think it is even better to write out TODO lists on paper and copy them when you run out of space with too much crossed out. The act of copying helps you review them, and I find any electronic solution is another window I have to find on my screen that distracts me from doing tasks.

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.

It depends.

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.

After that post I left basecamp https://world.hey.com/dhh/europeans-don-t-have-or-understand...

No. We use ClickUp now and will never go back.

I've been using it for a few years now, and I unfortunately strongly dislike it. I've never felt this disorganized before.

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.