|
> The key issue is “if you do it right”. That’s easy to type, but hard to execute. Indeed. In fact, everyone, including said seniors, will make the wrong decisions, will "do it wrong". So make sure the "do it wrong" is cheap. And the "do it right" compounds. Frameworks make "do it wrong" extremely expensive. If, after four years, you find that Symphony really was the wrong tool for your highly event-sourced bookkeeping, there's little you can do other that turning your Symphony into a personal version of it, or Rewrite It In Rust. Frameworks dictate far more than just the language and where to put stuff. They dictate how you test, how you host, deploy, how your team works, how long sprints can be, if scrum fits and so on. They get their tendrils in the entire project. Optimizing for "cheap failure" and "compounding interest on doing it right", IMHO does not go well together with many frameworks. |
That’s still really simple to type and hard to do.
> Frameworks make "do it wrong" extremely expensive. If, after four years, you find that Symphony really was the wrong tool for your highly event-sourced bookkeeping
1. It’s pretty simple to determine a framework’s architecture and design decisions a few months in, if not a few weeks or less
2. A “book keeper” application is such a basic commodity CRUD app, that it was exactly what a commodity framework was built for. Virtually every web based CRUD application is a conventional commodity.
Using a framework is optimizing for “cheap failure”. Creating your own inverted private framework feels like the exact opposite. All of the expensive mistakes possible with an open source framework, equally applies to your homegrown framework. The difference is that it took a lot more work and time to get to the same starting point.