My colleagues and I have been talking about this for the past 15 years. I have been contending that 'all' we have to do is supply the requirements and the machines would create the code. Bugs presumably would be a result of incomplete or incorrect requirements.
One of my colleagues has been consistently pushing back on that stating that you haven't reduced the amount of complexity you're managing. Your requirements have to get very detailed in stating how errors should be handled. It's all the 'rainy day' scenarios and alternative processing when errors are encountered that complicates things. Errors come in two flavors: business errors (these would be captured on a detailed business process diagram) and technical errors (for example an unreachable API due to network issues). You have to be careful how you map the technical details back to the business process and update your business process to handle technical errors.
Anyway, his point is this is all the complexity we deal with as architects, designers and developers and that it is complexity which makes development challenging. You can either deal with this complexity in the implementation (coding), or you can deal with this complexity in the specification (requirements - detailed to the likes I've never seen).
I've argued this is true, but its complexity of a different kind. Humans are very good at specifications. What we find difficult implementations. I know I'm hand-waving a bit, but it sounds like your colleague is proving me correct. Even if the amount of complexity is the same, by transforming it into a kind we are better equipped to handle, we make efficiency gains.
I would argue this isn't the case of 'Last Programmers' - you have to be a very good developer to make this work, as people are discovering. The next revolution will be systems created by those who never learned to code at all. I think we're quite a ways from that!
taylodl•2h ago
One of my colleagues has been consistently pushing back on that stating that you haven't reduced the amount of complexity you're managing. Your requirements have to get very detailed in stating how errors should be handled. It's all the 'rainy day' scenarios and alternative processing when errors are encountered that complicates things. Errors come in two flavors: business errors (these would be captured on a detailed business process diagram) and technical errors (for example an unreachable API due to network issues). You have to be careful how you map the technical details back to the business process and update your business process to handle technical errors.
Anyway, his point is this is all the complexity we deal with as architects, designers and developers and that it is complexity which makes development challenging. You can either deal with this complexity in the implementation (coding), or you can deal with this complexity in the specification (requirements - detailed to the likes I've never seen).
I've argued this is true, but its complexity of a different kind. Humans are very good at specifications. What we find difficult implementations. I know I'm hand-waving a bit, but it sounds like your colleague is proving me correct. Even if the amount of complexity is the same, by transforming it into a kind we are better equipped to handle, we make efficiency gains.
I would argue this isn't the case of 'Last Programmers' - you have to be a very good developer to make this work, as people are discovering. The next revolution will be systems created by those who never learned to code at all. I think we're quite a ways from that!