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!
AnimalMuppet•5mo ago
I agree with you up to your fourth paragraph. I'm not sure that the complexity is easier to deal with in architecture. In fact, architecture is easier at least partly because we don't have to deal with that level of complexity there. If we do, is architecture still easier?
I'd at least claim that it is unproven.
taylodl•5mo ago
My colleague disagrees with me on that point too! It's a good chat to have from time-to-time over a beer. To your point, not all of this is handled in architecture, nor should it be. I think we need to elevate our game for AI to be truly beneficial:
- SysML: formally capture requirements
- BPMN: formally capture and model business processes
- ArchiMate: formally capture and model architecture
- UML: formally capture and model design
AI can help with the above tasks, of course, but the point is that once you have these things and you've ensured your requirements have been captured in these models, again AI can help, then you hand the whole thing over to an AI code generator which now has enough informational context to generate good code.
Admittedly this is a pipe dream at the moment, and I seriously doubt we'll get there over the next 5 years, but the next ten years? Fifteen? Things can really start changing. Meanwhile, I see AI getting better and better at generating these models. Heck, we could start low tech with modeling wizards - like we've had for the past 30 years for code and be way ahead of where we are now.
taylodl•5mo 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!
AnimalMuppet•5mo ago
I'd at least claim that it is unproven.
taylodl•5mo ago
- SysML: formally capture requirements
- BPMN: formally capture and model business processes
- ArchiMate: formally capture and model architecture
- UML: formally capture and model design
AI can help with the above tasks, of course, but the point is that once you have these things and you've ensured your requirements have been captured in these models, again AI can help, then you hand the whole thing over to an AI code generator which now has enough informational context to generate good code.
Admittedly this is a pipe dream at the moment, and I seriously doubt we'll get there over the next 5 years, but the next ten years? Fifteen? Things can really start changing. Meanwhile, I see AI getting better and better at generating these models. Heck, we could start low tech with modeling wizards - like we've had for the past 30 years for code and be way ahead of where we are now.