3 ms·

>That spec will then become the source of truth, i.e. the thing to version-control. How is this a problem? This is already how PMs and engineering managers wor

>That spec will then become the source of truth, i.e. the thing to version-control. How is this a problem? This is already how PMs and engineering managers work: they tell individual contributors what to implement, hashing out any ambiguities or edge cases via natural language dialogs. They have no need to use version control on the code level; simply tracking changes to their high level spec works fine. >one might need to restrict oneself to a more well-defined subset of natural language that avoids ambiguities as far as possible. But then you're essentially back to programming. Again, PMs and engineering managers get by just fine with standard natural language.

codethief 4y ago
> How is this a problem? I never said this was a problem. > Again, PMs and engineering managers get by just fine with standard natural language. I agree only to some extent. At least in my experience, edge cases are often hashed out between the PM and engineers in spontaneous meetings, Slack conversations, or <insert medium of choice>. If ticket descriptions / acceptance criteria then get adapted accordingly, great. (Most of the time they don't – since we're so fucking agile.) Though, even if the descriptions/criteria do get updated, they often still lack precision and require interpretation – which is no problem, since all engineers now know what is meant by the ticket description and how to handle the edge case. However, if your entire spec is natural-language-based and you want your AI to reliably generate the same code every single time without needing to provide additional context, you better make sure to remove any ambiguity from the spec. But removing ambiguity from natural language basically comes down to speaking like a mathematicion / programmer, so the natural language spec will end up being rather similar to (pseudo) code again. So you're essentially back to programming.
dragonwriter 4y ago
> Again, PMs and engineering managers get by just fine with standard natural language. Actually, they often have lots of problems with “standard natural language”, which is why large projects tend to develop considerable volumes of specialized jargon (often multiple layers, such as project-specific, organization-specific, etc.), which is either subject to extensive documentation (which often becomes a maintenance issue) or which becomes a contributor itself to miscommunication as understanding gaps emerge as turnover and communications silos lead to differing understands among project team members and between the project team and other stakeholders. In fact, there is a lot of specialized, formalized, controlled language that is standardized beyond the organizational level (including visual languages), which is designed to mitigate parts of this problem (though it often fails, in part because usage in practice doesn’t consistently follow the formal standard.)
1270018080 4y ago
> PMs and engineering managers get by just fine with standard natural language. ...do they? Poorly defined requirements done through natural language could possibly be the most costly and wasteful aspect of any business.

codethief 4y ago

> How is this a problem? I never said this was a problem. > Again, PMs and engineering managers get by just fine with standard natural language. I agree only to some extent. At least in my experience, edge cases are often hashed out between the PM and engineers in spontaneous meetings, Slack conversations, or <insert medium of choice>. If ticket descriptions / acceptance criteria then get adapted accordingly, great. (Most of the time they don't – since we're so fucking agile.) Though, even if the descriptions/criteria do get updated, they often still lack precision and require interpretation – which is no problem, since all engineers now know what is meant by the ticket description and how to handle the edge case. However, if your entire spec is natural-language-based and you want your AI to reliably generate the same code every single time without needing to provide additional context, you better make sure to remove any ambiguity from the spec. But removing ambiguity from natural language basically comes down to speaking like a mathematicion / programmer, so the natural language spec will end up being rather similar to (pseudo) code again. So you're essentially back to programming.

dragonwriter 4y ago

> Again, PMs and engineering managers get by just fine with standard natural language. Actually, they often have lots of problems with “standard natural language”, which is why large projects tend to develop considerable volumes of specialized jargon (often multiple layers, such as project-specific, organization-specific, etc.), which is either subject to extensive documentation (which often becomes a maintenance issue) or which becomes a contributor itself to miscommunication as understanding gaps emerge as turnover and communications silos lead to differing understands among project team members and between the project team and other stakeholders. In fact, there is a lot of specialized, formalized, controlled language that is standardized beyond the organizational level (including visual languages), which is designed to mitigate parts of this problem (though it often fails, in part because usage in practice doesn’t consistently follow the formal standard.)

1270018080 4y ago

> PMs and engineering managers get by just fine with standard natural language. ...do they? Poorly defined requirements done through natural language could possibly be the most costly and wasteful aspect of any business.