Thanks jhenson29.
We're primarily discussing programming languages so it's somewhat easy to make general statements. Scale it to a larger more costly proposal, like control logic instead of micrologox to account for future requirements and you know that just doesn't work. It may not seem intuitive but the principal is the same, who are you designing for, you or the customer?
Which brings us back to my question about validation, when do you validate those add requirements and how do you present them?
You and Toine explained quite well a method of breaking code to manage and hide (my word) the complex parts and find other ways (HMI diagnostics) to meet stakeholders requirement, that's great. But that still has to be approved by them way before much time and money is invested.
Adding my own requirement to the customer's and proceeding with design on that basis is just too risky.
We're primarily discussing programming languages so it's somewhat easy to make general statements. Scale it to a larger more costly proposal, like control logic instead of micrologox to account for future requirements and you know that just doesn't work. It may not seem intuitive but the principal is the same, who are you designing for, you or the customer?
Which brings us back to my question about validation, when do you validate those add requirements and how do you present them?
You and Toine explained quite well a method of breaking code to manage and hide (my word) the complex parts and find other ways (HMI diagnostics) to meet stakeholders requirement, that's great. But that still has to be approved by them way before much time and money is invested.
Adding my own requirement to the customer's and proceeding with design on that basis is just too risky.
