4 ms·

So much of what passes for 'requirements gathering' in software development historically has consisted of precisely this kind of heuristic-collecting. Trying to

So much of what passes for 'requirements gathering' in software development historically has consisted of precisely this kind of heuristic-collecting. Trying to come up with rigorous rules for, as here, 'when should we serve cocktails on planes', so we can build software that enshrines those rules, so that at some point, someone will be refused a cocktail under circumstances when one might help. Congratulations, software engineers. You made someone's day a little worse. The goal of software engineering isn't to make rules lawyers that implement the same logic as staff do only with less imagination and discretion. That's just a shortcut to reducing staff numbers while making worse decisions and reducing service quality. The goal of software engineering should be to make systems that can support making better decisions. The rules your staff use today to figure out what flights should serve cocktails are themselves policies that evolved in service of some broader business goal, taking into account behind the scenes information like service costs, customer satisfaction, competitive analysis, brand intentions, etc. Build software that supports that process.

rramadass 3y ago
I am not sure i understand your argument. The process of "requirements gathering" is by definition heuristic and iterative. The point of encoding it via "Decision Tables" (or any other technique) by a Domain Expert/Software Engineer is to be precise/rigorous so that it can be easily translated into computer code unambiguously. The usage of the above will vary industry by industry depending upon their needs i.e. "Technical aspects" vs. "Social aspects". Thus a Nuclear Plant Manager/Aeroplane Pilot will be tightly confined within set bounds while Retail industry/Customer care will have a lot more leeway to consider the "Social aspects" involved. This can only be solved by "Human Resources Training" over and above Computer-aided support. The field of "Decision Support Systems" (https://en.wikipedia.org/wiki/Decision_support_system https://en.wikipedia.org/wiki/Decision_support_system) is well established and supports a wide spectrum of both Computer and Human factors.
tunesmith 3y ago
I think the article probably used a bad example. I think the intent was to pick an example that is easy to understand even for non-programmers - the rules behind serving cocktails on flights - rather than imply that this technique is intended for social rules that humans should follow. If instead imagined to apply toward some of the complicated logic we regularly come across in actual computer programming, it starts to feel more useful. As programmers we've all come across cases of snarly boolean logic that nests multiple levels deep. In those cases, I've found decision trees very useful. I've taken it to the point of literally listing out every combination of conditions, rather than just the ones that seem to apply. Through that you can sometimes discover corner cases that need to be accounted for. Other times, you realize that you can collapse parts of the state so that your end-result conditional logic becomes much simpler. If you've ever had that case where you realized that your third-level internal condition could be moved to the outermost condition, thereby simplifying the code significantly, then that's what the exercise helps with.

rramadass 3y ago

I am not sure i understand your argument. The process of "requirements gathering" is by definition heuristic and iterative. The point of encoding it via "Decision Tables" (or any other technique) by a Domain Expert/Software Engineer is to be precise/rigorous so that it can be easily translated into computer code unambiguously. The usage of the above will vary industry by industry depending upon their needs i.e. "Technical aspects" vs. "Social aspects". Thus a Nuclear Plant Manager/Aeroplane Pilot will be tightly confined within set bounds while Retail industry/Customer care will have a lot more leeway to consider the "Social aspects" involved. This can only be solved by "Human Resources Training" over and above Computer-aided support. The field of "Decision Support Systems" (https://en.wikipedia.org/wiki/Decision_support_system https://en.wikipedia.org/wiki/Decision_support_system) is well established and supports a wide spectrum of both Computer and Human factors.

tunesmith 3y ago

I think the article probably used a bad example. I think the intent was to pick an example that is easy to understand even for non-programmers - the rules behind serving cocktails on flights - rather than imply that this technique is intended for social rules that humans should follow. If instead imagined to apply toward some of the complicated logic we regularly come across in actual computer programming, it starts to feel more useful. As programmers we've all come across cases of snarly boolean logic that nests multiple levels deep. In those cases, I've found decision trees very useful. I've taken it to the point of literally listing out every combination of conditions, rather than just the ones that seem to apply. Through that you can sometimes discover corner cases that need to be accounted for. Other times, you realize that you can collapse parts of the state so that your end-result conditional logic becomes much simpler. If you've ever had that case where you realized that your third-level internal condition could be moved to the outermost condition, thereby simplifying the code significantly, then that's what the exercise helps with.