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.
(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'.)