Why would you write a ~9k “loc” long spec over 6 month instead of coding it directly ? The only reason I can think of, is if you want to out-source the development. Is there any good reason to work this way on a one-man project ?
(before the obvious objection: exceptions are toy programs which you write to find out how to build something, in which you focus on the technical aspects. The technical aspects ('how does it work') don't matter for the end user (= your potential customer), they only care about 'what does it do'.)
Most colleagues of mine and a few managers see them as a waste of time ("you're over thinking this", or "we'll figure it out later") yet somehow the projects with a specification always end up being done more or less on schedule.
The thing about specifications is that you need to be open to changing them if you find it's not working out. Specifications are not synonymous with waterfall development, and it's harmful to treat and view them as such.
Planning is important, and cautiously thinking about your features before diving in can save you weeks later on. But spending 6 month in a tunnel, writing specs you'll spend at least a year to implement, is a huge risk : what if your users only use 30% of the features you designed, and lack a missing feature you didn't plan ? You could have figured it out way sooner have you built something earlier and released it.
Also, your time to market is way slower and you don't risk losing years of work by missing a deadline …
> Damn, now I need to move faster. My app must be ready by the time they close Wunderlist. I expected an eventual closure, but not that soon.
Or worse, what if different segments of users only use 30% of different feature sets? See also: Evernote's 5% problem [1]
[1] https://venturebeat.com/2016/01/05/evernotes-5-problem-offer...
Yeah but that's not necessarily in man-years. Maybe he worked on it an hour or two a day. Now we're talking around two man-weeks of planning.
(Not the OP.) At least for me, emphatically yes.
From your question, it sounds like you're only considering the communicative value of a spec. That's of course important, but I consider it secondary.
Writing a good spec forces you to think through what you're developing in an orthogonal way. You're thinking through flow, cohesiveness, design, some implementation, UI, etc. together at a high level.
I love having the time to write a spec when I'm building something nontrivial. I've found numerous problems that I wouldn't have otherwise by doing so, ranging from simple UI problems/contradictions to spotting unconsidered assumptions that would have lead me down dead ends.
A spec and the application should naturally co-evolve during development to some extent. But the spec also provides an anchor for what you're doing, as well as a map. It is very, very helpful if you Do It Right(tm), no matter the size of your team.
(OP here). This. A thousand times this.