4 ms·

Agree with you on the article but have to part ways with you from there. > The issue isn't that development is hard (though it is), it's that you have to trans

Agree with you on the article but have to part ways with you from there. > The issue isn't that development is hard (though it is), it's that you have to translate human, squishy requirements that have unconsidered edge cases to machine considerations which have no room for ambiguity. This is a tired old meme. And I didn't believe it when it was a young whipper-snapper neither. Define 'squishy'. You can't, can you? What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Why can't a machine handle ambiguous input? It could defer to the operator, did you mean this? did you mean that? It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty (both true and false are epistemic locations of absolute certainty).

rorykoehler 11y ago
>It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty. Essentially this is how humans operate already. How many times a day do you have minor but insignificant misunderstandings with people? Probably quite often, especially if you are in a foreign country and yet we all get along just fine.
arethuza 11y ago
"squishy" is about as good a word for most initial requirements as I have ever heard. Turning squishy requirements into something specific enough to actually design a solution around is a pretty important step in any project.
coldtea 11y ago
>Define 'squishy'. You can't, can you? Is that supposed to be a counter-argument? Because, that's the parent's whole point: that the same (they can't be defined or at least defined easily) holds for those "squishy human requirements". >What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Obviously the fact that they only follow specific instructions at their lower level, and thus any ambiguity has to be explicitly translated to a non-ambiguous set of commands. A fellow human does this translation automatically in their mind (and even they, not always perfectly). >Why can't a machine handle ambiguous input? It could defer to the operator, did you mean this? did you mean that? It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty (both true and false are epistemic locations of absolute certainty). Most of these sound recipes for disaster in any practical application... And even that's besides the point, since all of these need to be programmed just as well as non ambiguous commands, but with more branching and special casing -- again explaining why handling ambiguity is hard. Oh, and "randomly choose from a number of possible ways to continue" sounds like Clippy from hell...
mooreds 11y ago
Thanks for the feedback. I find it generally interesting because most technical folks I've talked to have the same attitude I do. (Upvoted.) > What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Of course, if designed for ambiguity, information machines can handle it. But in my experience, solving a problem with software first involves defining the problem. Most problems are "squishy", in that they are ill defined. The end user has needs and knows those needs, but hasn't thought through all the ramifications of automation. I've started a requirements process many a time with the question: "what do you want this to do", and then diving down to specify each behavior, including critical path functionality, error conditions, alternate paths, roles in the system, performance, timeframes, and other attributes. All of these are fundamental pieces of automating information flow, but aren't typically considered by a non technical person. Hence my use of the term "squishy". (I wrote a blog post in 2003 about how software crystallizes business processes: http://www.mooreds.com/wordpress/archives/46 http://www.mooreds.com/wordpress/archives/46 ) And I don't know of any software process that can handle that. Even tools designed for non developers like Excel and Zapier force users to go through edge cases. Finally, I'm certainly no expert on some of the new AI technologies that might be game changers. (I did enjoy reading The Master Algorithm, which talks about the schools of AI and some of the achievements.)
- igravious 11y ago
  I definitely could have phrased my objections to what you wrote in a less provocative manner. My bad. So thank you for the level-headed response to my feedback. > Of course, if designed for ambiguity, information machines can handle it. I thought you were implying they couldn't. I just had flashbacks to too many arguments with people who don't get how computers work where they claim that machines are just ones and zeroes, on or off, black or white, and humans are so many shades in between. What do the kids these days say? triggered I didn't get that you were referring to the process of capturing user requirements. I can see in that context why you would call that process 'squishy'. I wouldn't disagree with you on that, then it's probably a perfectly good work to describe that open-ended, frustrating! iterative process of discovery and refinement. I really asked for those down-votes with the tone and manner in which I first replied to you. :/ Let some bad news I received filter through there. sigh
gherkin0 11y ago
> Define 'squishy'. You can't, can you? Underspecified. Understanding, correctly, what an underspecified system should do is a strong AI problem (in most cases, at least). All (or nearly all) unbuilt systems are underspecified (as well as many built ones). We do not yet have strong AI. Hence, we have developers who will continue to collect paychecks for the foreseeable future (your "tired meme"). > What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Why can't a machine handle ambiguous input? Your focus on "ambiguous input" misleads you. The difficulty is more like ambiguous output.

rorykoehler 11y ago

>It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty. Essentially this is how humans operate already. How many times a day do you have minor but insignificant misunderstandings with people? Probably quite often, especially if you are in a foreign country and yet we all get along just fine.

arethuza 11y ago

"squishy" is about as good a word for most initial requirements as I have ever heard. Turning squishy requirements into something specific enough to actually design a solution around is a pretty important step in any project.

coldtea 11y ago

>Define 'squishy'. You can't, can you? Is that supposed to be a counter-argument? Because, that's the parent's whole point: that the same (they can't be defined or at least defined easily) holds for those "squishy human requirements". >What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Obviously the fact that they only follow specific instructions at their lower level, and thus any ambiguity has to be explicitly translated to a non-ambiguous set of commands. A fellow human does this translation automatically in their mind (and even they, not always perfectly). >Why can't a machine handle ambiguous input? It could defer to the operator, did you mean this? did you mean that? It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty (both true and false are epistemic locations of absolute certainty). Most of these sound recipes for disaster in any practical application... And even that's besides the point, since all of these need to be programmed just as well as non ambiguous commands, but with more branching and special casing -- again explaining why handling ambiguity is hard. Oh, and "randomly choose from a number of possible ways to continue" sounds like Clippy from hell...

mooreds 11y ago

Thanks for the feedback. I find it generally interesting because most technical folks I've talked to have the same attitude I do. (Upvoted.) > What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Of course, if designed for ambiguity, information machines can handle it. But in my experience, solving a problem with software first involves defining the problem. Most problems are "squishy", in that they are ill defined. The end user has needs and knows those needs, but hasn't thought through all the ramifications of automation. I've started a requirements process many a time with the question: "what do you want this to do", and then diving down to specify each behavior, including critical path functionality, error conditions, alternate paths, roles in the system, performance, timeframes, and other attributes. All of these are fundamental pieces of automating information flow, but aren't typically considered by a non technical person. Hence my use of the term "squishy". (I wrote a blog post in 2003 about how software crystallizes business processes: http://www.mooreds.com/wordpress/archives/46 http://www.mooreds.com/wordpress/archives/46 ) And I don't know of any software process that can handle that. Even tools designed for non developers like Excel and Zapier force users to go through edge cases. Finally, I'm certainly no expert on some of the new AI technologies that might be game changers. (I did enjoy reading The Master Algorithm, which talks about the schools of AI and some of the achievements.)

igravious 11y ago
I definitely could have phrased my objections to what you wrote in a less provocative manner. My bad. So thank you for the level-headed response to my feedback. > Of course, if designed for ambiguity, information machines can handle it. I thought you were implying they couldn't. I just had flashbacks to too many arguments with people who don't get how computers work where they claim that machines are just ones and zeroes, on or off, black or white, and humans are so many shades in between. What do the kids these days say? triggered I didn't get that you were referring to the process of capturing user requirements. I can see in that context why you would call that process 'squishy'. I wouldn't disagree with you on that, then it's probably a perfectly good work to describe that open-ended, frustrating! iterative process of discovery and refinement. I really asked for those down-votes with the tone and manner in which I first replied to you. :/ Let some bad news I received filter through there. sigh

gherkin0 11y ago

> Define 'squishy'. You can't, can you? Underspecified. Understanding, correctly, what an underspecified system should do is a strong AI problem (in most cases, at least). All (or nearly all) unbuilt systems are underspecified (as well as many built ones). We do not yet have strong AI. Hence, we have developers who will continue to collect paychecks for the foreseeable future (your "tired meme"). > What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Why can't a machine handle ambiguous input? Your focus on "ambiguous input" misleads you. The difficulty is more like ambiguous output.