Breaking with this sort of practice is exactly why agile development and it's ilk were born.
While writing a formal specification can be useful, it is rarely as useful as defining the problem and placing your solution in the context of other possible solutions.
I've been lucky enough to attend one of Peyton Jone's talks in person. He is not suggesting to "write a formal spec" before you do research. In contrast, his attempt is to be agile: keep going back and forth in the paper writing as you do research. Only then you will see what's missing.
Essentially, what he is suggesting is actually "agile academic research", compared to the "waterfall academic research" (do stuff, then write-up a paper with what you've got...)
Comments
Which is the 3rd circle of hell.
Breaking with this sort of practice is exactly why agile development and it's ilk were born.
While writing a formal specification can be useful, it is rarely as useful as defining the problem and placing your solution in the context of other possible solutions.
I've been lucky enough to attend one of Peyton Jone's talks in person. He is not suggesting to "write a formal spec" before you do research. In contrast, his attempt is to be agile: keep going back and forth in the paper writing as you do research. Only then you will see what's missing.
Essentially, what he is suggesting is actually "agile academic research", compared to the "waterfall academic research" (do stuff, then write-up a paper with what you've got...)