Show HN: Mainline – a project tool with no backlog, story points or surveillance(mainline.dev)

5 pointsby natyoungvor 2 Monaten0 comments

Show HN: Mainline – a project tool with no backlog, story points or surveillance

https://mainline.dev/demo

I've spent the last fifteen years walking into engineering orgs that said they did "CI/CD" (there's no such thing, CI and CD are distinct practices) and "Agile", and proceeded to ship annually through release ceremony and theatre. There are more than a few dark-agile patterns I'm sick of seeing, so I built a project management tool that avoids them, and that exists to be a counterweight against the tools that encourage them.

The notion of story points was the first thing to go. Even Ron Jeffries, who invented them, regrets their usage. Mainline hard-codes a story size of 1 and tracks whether each story falls outside the team's normal distribution of time from start to release. After a few weeks the team has a real handle on their cadence, backed by data instead of planning-poker theatre. No estimation meetings required. Just do the work.

Unreleased work is made visible and tracked as inventory. There's a cottage industry of hosted feature-flag platforms selling a different idea to the original technique. Long-lived business-facing flags create waste in the form of unmanaged inventory left hanging around past its usefulness. Worst case, they become a giant configuration surface that "tech debt" doesn't do enough to capture as a term. Mainline tracks branch-by-abstraction, dark launches, feature flags, and old stories in flight through three phases: in progress, ageing, and stale.

The backlog is replaced with a Story Map. Work is shown as a user journey, and if it's not on the map (or has no user persona associated) it doesn't exist. This makes it harder for someone to dump tech tasks or random work onto the team for the purpose of "having a backlog."

The collaboration patterns high-performing teams use are first-class. Ensemble, pairing, and solo work are all visible and tracked, which makes de-siloing legible and promotes co-ownership.

I resisted adding AI features. It would be a weekend's work, and it would also undo the whole point. The longer argument is at mainline.dev/docs/ai.

I started building this with event sourcing and CQRS because I wanted the app built around an immutable event log. It wound up being too much boilerplate to change anything simple. So I went with an RDBMS and transactions to implement the immutable event log instead.

As I've learned after watching dozens of microservice teams utterly fail to safely ship anything, I took my own advice and started with a boring monolith and RDBMS. The stack itself is boring on purpose: Ruby with Roda and Sequel, Puma with YJIT, deployed via Kamal to Hetzner.

For teams who want to get better at CI, I built an integration with GitHub (GitLab coming) that reads the repo statuses and tracks how long a branch (if any are used) is open for. It's just a red/green dot on the repos as a heads-up.

The live demo is at mainline.dev/demo. No signup required, read-only because it's one shared team.

I'd be interested in feedback on how else I can help teams get better at CI and CD, and on any gripes you have with the parasitic management layer of non-practitioners who use other tools to implement Taylorist methods. Also, any other features that I haven't thought of (or thought of removing).

0 comments

—