> The "one size fits all" approach: Assuming that every task will take the same amount of time is a recipe for disaster. Different tasks have different complexities and require different skill sets.

I sometimes wish we lived in a world where we'd have enough data to accurately predict at least the common tasks, thus freeing people up to reason about the more complex tasks.

For example: adding a new path to a webapp, which will resolve to a Ruby on Rails template, that needs 2 dropdowns and 3 input fields, which need input validations and checks against already saved DB data on saving will take around X hours of work. Doing this with Python and Django will take around Y hours of work. Using a certain set of tools to assist with development will affect these estimates by Z hours.

But I doubt anyone ever has data that granular.

I think once we get to the point where the design is so fixed for a set of standardised tasks like that, that we know how long it will take, the design is also so fixed that we can run a script that generates the code for it, so the time to make it is close to zero.

For all of the boilerplate stuff, I fully welcome and embrace it. For example, we already have codegen for various stacks, even Ruby on Rails: https://guides.rubyonrails.org/generators.html

Sadly, model driven development never really took off, because seemingly everyone was interested in being able to iterate and ship new features in frameworks quickly, as opposed to slowing down and working on different ways to interact with what's already there.

SOAP had WSDL, but REST needed a whole bunch of time until we got OpenAPI and levels of codegen that SoapUI had years ago: https://github.com/OpenAPITools/openapi-generator

MySQL Workbench also has great bi-directional ER diagram support, with forward/backward engineering and schema sync: https://dev.mysql.com/doc/workbench/en/wb-design-engineering...

But maybe I'm asking for too much, generating templates for views with model fields, or even model bindings for the ORM is already good, as is generating DB migrations as well.