>This isn't either/or. To engage with JE's particular essay, I think it is either /or. He emphasized "prose" with italics. Seems a reasonable interpretation

>This isn't either/or. To engage with JE's particular essay, I think it is either /or. He emphasized "prose" with italics. Seems a reasonable interpretation is that he thinks the rigid or incorrect structure in Jira is wrong to document a macro vision. If he thinks another structured tool like MS Excel or MS Project is a desirable alternative, it seems he would have mentioned it. Instead, he recommends prose. To be pedantic, one can type "prose" right into Jira. But that would be an uncharitable reading of his essay. Therefore, he must mean something else: a document that's more freeform. >I read it a call for an iterative and evolving "design" that comes from the program as it is run If he meant that, he's wrong because the running program is always an incomplete picture of what you desire the program to do. The "desires, goals, and design" -- ultimately has to be stored outside of the source code and therefore, it can't be a source of truth for that type of macro vision. (Yes, there is a school of thought that proposes that "the source code _is_ the design" but I've always seen that as more of a reaction to UML diagrams and flowcharts from CASE tools that get out of sync with the actual code. To really fulfill the "code is design", it would require an extremely powerful declarative language compiler that turns high-level English specifications into executable code. Using today's primitive languages such as cpp and h files isn't a good way to express "code is design".)