How Software Begins to Rot
Proper building construction is to have a proper design which includes all latest state-of-the-art components and follow all safety precautions. The building won’t collapse and it will be great. If you however use this approach with software, you will fail.
The thing is, when the building is done, it is done. Nobody will suggest to add more elevators or change the grounding. An intelligent design, and a total opposite to a software which is an ever-changing reshaping blob. A living, breathing organism where anything may be subject to change. It is never really done, and initial architecture rarely survives more than three years.
By using lots of frameworks in the software project, albeit with best intents, you will create bonds which artificially slow down the shape-shifting. Too many bonds, and the software will stop moving, it will die, it will start rotting and it will turn into a rotting steaming spaghetti of framework workarounds and annotation magic. Your devs will waste time figuring out how to get around the framework limitations. Good developers will get frustrated by the slow pace and they will leave. The software will attract framework fanatics. Under the guidance of bad developers piling workarounds upon hacks, the team will repulse any good programmers. The software ecosystem now reached terminal state and the software now starts to rot. Good luck finding a team of good programmers that can now restart your project afresh.
To avoid software rot, be careful when adding frameworks, and remember to remove them when they no longer serve any purpose and deliver no value in your software. Only by focusing on simplicity, you will be able to evolve the software quickly.
Remember: Simplicity is the best future-proof that you can have in your software.
This is the most important guiding principle in the Vaadin on Kotlin framework.