| I've streamlined all my processes to the point that I can build a reasonably scalable system (including user management, app, ACLs, file management, custom queries, REST API points, websocket integration) in a couple of hours. It's boring for a developer. I don't understand many of the problems described here (e.g. people complain about the complexity of server management, complexity of web frameworks and web in general). Actually it has become more simple than ever to create an app, a backend and scale the system. With more servers (I use systems that can be scaled horizontally) thrown at it, good caching and some load balancing, it will work for 99% of businesses. Here [1] is a good description of a service that uses this thinking. I believe there are many who celebrate complexity. Otherwise I can't understand most codebases - I've seen terrible codebases with big LoC's where I was able to reimplement the whole feature set in a couple of days. I believe many programmers don't want to see that their jobs become increasingly easy to do and the boilerplate can be reduced by 90%. > We don't dream of having to maintain complex machineries reminding us of Rubik's cubes. Many people do because their jobs depend on it. If businesses would adopt those fast, clean and scalable engineering techniques, 70% of the work force is no longer needed. It's basically the principal-agent problem [2] in action. [1]: https://medium.com/unboxd/how-i-built-an-app-with-500-000-us... [2]: https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble... edit: in terms of "No Silver Bullet" - I think if we decrease accidental complexity (using good techniques and automated and tested systems) to a record low, we won't need as many people to manage the essential complexity. In my experience the problem of complexity is another one: big enterprise makes a lot of money using their terrible code. They will keep throwing money at it to avoid major rewrites. Programmers will complain about unnecessary complexity, but complexity is not what's important for the bottom line most of time. The system just works and prints money, so there's no need to correct (until it explodes in complexity, but a major rewrite is also a risky decision for managers and can result in huge investment losses). |