Skip to content

Comment on How to Write an Effective Software Design Document

Comments

The "what's the penalty for being wrong" question is the part I'd keep. That one works at any scale.

But I spent five years on a solo app and never wrote anything close to this. Not on principle event, just the design just kept moving. The decisions that ended up mattering weren't ones I could have named on day one, they were things I cut in year three once I actually understood what the app was for. If I'd written the objective sentence up front I'd have locked in a version that turned out wrong. The clarity came from building the thing, not from describing it first.

For coordinating people or catching a security flaw before it ships, sure, all of this makes sense. Solo just runs on different rules I guess.

Thanks for reading!

But I spent five years on a solo app and never wrote anything close to this. Not on principle event, just the design just kept moving.

Yeah, I agree that for solo projects, it makes sense to greatly scale down the design phase. In a lot of cases, you'd scale design down to zero if you need user feedback to figure out what to build.

But even for solo projects, if I keep at it for months or years, I eventually get to the point where some problem is hard enough that I need to do some upfront design, even if it's not as formal as a whole design doc.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.