4 ms·

> I'm not sure what Jon Evans means by "prose" to document the "macro vision"... a freeform text file? MS Word doc? Yes. Sometimes. > Personally, I need more

by geocar 8y ago

> I'm not sure what Jon Evans means by "prose" to document the "macro vision"... a freeform text file? MS Word doc? Yes. Sometimes. > Personally, I need more structure than that so I use a spreadsheet for it. I like to create columns of metadata to assign a priority, notes about difficulty, estimated time, estimated cost, etc. I think having a spreadsheet is good too. This isn't either/or. > Yes, the source code is a "source of truth" but it's only truthful at the abstraction level of generating an executable. It's the wrong abstraction for gathering wishlists and future goals and priorities. I don't think that's what is meant by this statement: the source of truth is always the running code. I read it a call for an iterative and evolving "design" that comes from the program as it is run, instead of some repository of code or tickets.

jasode 8y ago
>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".)
- geocar 8y ago
  I think you misunderstood me/I was unclear. Yes, the macro-level view belongs in prose. In a word-doc perhaps. All I meant was that this doesn't preclude the use of tools like Excel (or Jira) to break up tasks into items and estimate their cost. If you like doing that, then great: you're not doing anything wrong.

by geocar 8y ago

jasode 8y ago

>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".)

geocar 8y ago
I think you misunderstood me/I was unclear. Yes, the macro-level view belongs in prose. In a word-doc perhaps. All I meant was that this doesn't preclude the use of tools like Excel (or Jira) to break up tasks into items and estimate their cost. If you like doing that, then great: you're not doing anything wrong.