[saltedmd5]

The truth is that the construction of CRUD web UIs _is_ 90% automated.

The web and storage frameworks do the vast majority of the heavy lifting - the application code is really just simple wiring and validation.

The trouble is that (in my experience, at least) many web shops and web developers enormously overcomplicate that application code; shoehorning enterprise "layering" into simple components, creating poor - and often unnecessary - abstraction. These things lead to grossly over-engineered solutions with bloated code and control flow flying all over the place.

So the reality is that what can be automated largely is already - we are just, by and large, pretty bad at doing the bit that isn't.

[staticelf]

One can compare it to any other product in the real world. Just think about cars. Every car is about the same nowadays, many uses the same parts under the hood. But still, every car has different functions, different designs and slightly different placement of things UI-wise.

This is the state of the development world as well. It is like this because not everyone wants the same generic model and every company has to stick out in some way.

[mattbrewsbytes]

The thing about cars, or any real-world comparison, is that software is always changeable. Its hard to change manufacturing lines over a new design for cars, thats why they have designs out there for years at a time.

I think the vast majority of our time isn't wiring a UI to CRUD actions, its dealing with the complexities of whatever business domain the CRUD app is intended.

[shubb]

It's also worth pointing out that the design cost of a new model of car (which is equivalent to a new VERSION of an existing software product) is at least 1 billion dollars.

If a really good big crud app costs 100k on upwork is more similar to remodelling an office. In many ways.

http://bramaindustries.com/wp-content/uploads/2015/05/office...

[staticelf]

Software is changeable but I think it's hard to change stuff for large applications as well. Just think of the massive work that goes into redesigning an enterprise application that users have been using for years.

It's not that easy..

[dabockster]

> not everyone wants the same generic model and every company has to stick out in some way

You also have all those little edge cases that do not fit in a generic CRUD model.

[rtpg]

My experience has been that shops that avoid abstraction (namely, lacking a strong separation between controller code and business logic) end up suffering a decent amount long-term.

There's an argument that many layers of abstraction lead to too much boilerplate, but lacking abstractions can cause slowdown long-term because it gets harder and harder to handle all the interactions between subsystems.

You can always automate boilerplate "generation". You can't automate inconsistent business logic.

[saltedmd5]

The problem is the idea that "layers" and "abstraction" come as a package. You don't need layers to create meaningful and useful abstraction - in fact more often than not they prohibit it.

And you certainly don't need layering within a single codebase - if I see one more codebase where everything is a FooController, FooService or FooRepository I just might go insane.

People abstract logic away from controllers only to dump it all into a massive procedural "service" class, which leads to no end of pain down the road. Once you stop seeing layers and start seeing a vertical dependency tree starting at the controller, the world gets a lot more rosy. Consumer-driven development helps here.

[bryanrasmussen]

layers of abstraction may help agencies that move between different projects for different companies in first of all being able to reuse what they have done between their customers, but also in building something that someone else will find difficult to maintain - thereby providing lock-in.

[youthclub]

Interesting, this is how most of our code ends up . But the service abstraction has been beneficial for our other applications which consume them too. I’m going to read closely about Comsumer driven approach though.