Specs are great for short term discussions about requisites and implementation.
But there’s this old adage, “Confluence is where knowledge goes to die”. I don’t think I’ve ever worked at a company where this wasn’t true.
If you write a spec, there’s a non zero chance that nobody will update it in a year, because it has no effect to the bottom line, and engineers have to be willing to look them up every time they make changes to code, which is never the case.
I think this will depend on the industry. Slow vs fast moving, regulated vs not, whether someone depends on your API or not, etc.
But regardless, having had to deal with some legacy code written 10 years ago by someone who isn’t working at the company anymore, I would take an outdated spec over none at all. At least then I know what people intended back then, what they cared about, what they had and hadn’t considered. As long as the spec is written by a human, that information is surely valuable.
Specs are great for short term discussions about requisites and implementation.
But there’s this old adage, “Confluence is where knowledge goes to die”. I don’t think I’ve ever worked at a company where this wasn’t true.
If you write a spec, there’s a non zero chance that nobody will update it in a year, because it has no effect to the bottom line, and engineers have to be willing to look them up every time they make changes to code, which is never the case.
I think this will depend on the industry. Slow vs fast moving, regulated vs not, whether someone depends on your API or not, etc.
But regardless, having had to deal with some legacy code written 10 years ago by someone who isn’t working at the company anymore, I would take an outdated spec over none at all. At least then I know what people intended back then, what they cared about, what they had and hadn’t considered. As long as the spec is written by a human, that information is surely valuable.