Perhaps try walking them through, one-on-one or in small groups ideally, use cases of software you have to develop. As they describe the use cases, identify points in the case where different things could happen (unexpected but not unreasonable cases). Start to enumerate them, ask for some clarifications, and illustrate all the decisions and directions that need to be made or settled on, and the trade-offs being made in doing so. Keep going until they are stumped and can't give you an answer. Get them to understand that, what you're doing now with them, is exactly what you do all day, probably on your own, probably with a lot less clear direction, both deciding the course and writing the code, for hundreds or thousands of use cases that may or may not even be laid out by anyone. And when there's a case you had not thought of yourself, you can't guarantee what the program will do. Maybe it does the "right" thing, maybe note. And that's what a bug is. And that's why writing software takes time. The less time you have, the less cases that you had a chance to consider and accommodate, and the more likely the program will not do the "right" thing in an unknown circumstance.