4 ms·

I think this is all valid. What I think bears highlighting is that often you don’t need a 100% unambiguous specification. Very often “meets the business require

by dpark 6mo ago

I think this is all valid. What I think bears highlighting is that often you don’t need a 100% unambiguous specification. Very often “meets the business requirements” if totally sufficient and plenty of other stuff is either implicit or just doesn’t really matter. If you need to develop an API that you’ll support publicly for 10+ years, yeah. You probably want to be really precise. If you need to code up yet another feature in some CRUD app, it matters a lot less. Sometimes natural language is entirely sufficient to “unambiguously describe the details that are important”.

HarHarVeryFunny 6mo ago
Sure, there are some cases where "business requirements is all you need", and certainly CRUD apps are the poster child for this. However, no/low-code solutions for things like this have existed basically forever, way before AI (I remember "The Last One" from the 1980's that was going to make custom coding obsolete), and yet people still mostly prefer to hand code CRUD apps. It's interesting to guess why this is the case. Is it just because writing code that is 100% boilerplate is so simple that automation has no value, or is it that even in this simplest of cases that there is in fact still some human taste/skill being applied so that the app doesn't just "meet business requirements", but also doesn't suck, and/or maybe seeing as the business wants someone to call and fix it when it inevitably stops working, you may as well have that person write it in the first place? No doubt there are other factors too. I guess the multi-billion dollar question is how much of software development overall consists of CRUD-like "business requirements are all you need" type applications, vs how many need some actual software engineering, and time will tell how many companies end up choosing to use automation tools to write software, vs the CRUD situation where despite this having been possible for a long time, hardly anyone chooses to do so for a myriad of other reasons.

by dpark 6mo ago

HarHarVeryFunny 6mo ago

Sure, there are some cases where "business requirements is all you need", and certainly CRUD apps are the poster child for this. However, no/low-code solutions for things like this have existed basically forever, way before AI (I remember "The Last One" from the 1980's that was going to make custom coding obsolete), and yet people still mostly prefer to hand code CRUD apps. It's interesting to guess why this is the case. Is it just because writing code that is 100% boilerplate is so simple that automation has no value, or is it that even in this simplest of cases that there is in fact still some human taste/skill being applied so that the app doesn't just "meet business requirements", but also doesn't suck, and/or maybe seeing as the business wants someone to call and fix it when it inevitably stops working, you may as well have that person write it in the first place? No doubt there are other factors too. I guess the multi-billion dollar question is how much of software development overall consists of CRUD-like "business requirements are all you need" type applications, vs how many need some actual software engineering, and time will tell how many companies end up choosing to use automation tools to write software, vs the CRUD situation where despite this having been possible for a long time, hardly anyone chooses to do so for a myriad of other reasons.