Totally with you. I've been thinking of it as rewrite-friendliness, and have some ideas for encouraging it: http://akkartik.name/about
Even if people don't believe that all code over five years old is doomed, writing code to be easy to rewrite still seems like a useful idea. You're preserving optionality, you're making it easier to try out multiple designs, and you'll have an easier time recruiting collaborators because they'll have more fun projects to try, and so they'll be more likely to progress 'down the funnel' from using a project to hacking on it to contributing it all the way to taking over its running.
I love your website. My experience (web app for heavily regulated industry):
- Customers don't want major versions to be continuously deployed. Each deployment involves validation and training. They want the software to be left alone, perhaps with the occasional bug fix.
- The business needs new features to stay competitive.
- So you're left actually needing to host multiple versions. All the major versions the customers are on, and want to stay on, and one latest-and-greatest version for winning new business.
- Never force a new feature on a user. It becomes obvious that you're building things that most of your customers don't want. This means don't create a major version and automatically deploy it.
- Moving data between systems is hard. Plan to never move data between systems, or major versions of the same system. Users prefer to see their data where they left it, looking exactly how they left it. A major version should be empty. If you constrain a new version of your software based on old data, sooner or later you're stuck, either because of schema or because of volume.
- So if you have a big new feature, you save it for the next rewrite.
- Once you've decided that at some point in the future you're going to do a rewrite, things fall into place nicely...
- You avoid the situation where your dev team is mostly useless apart from the few guys who originally wrote the system.
- You avoid the endless accumulation of data.
- You avoid being commanded by the product team.
- You avoid being hated by your users, and your clients.
- You avoid spending huge amounts of time and money on things you didn't really need to do.
- You avoid the end of your business, which is inevitable given ~10 years of 'current best practice'.
- The part that I don't know yet is... developers have been avoiding rewrites for so long, we haven't really got good at it. We need to do it, do it often, learn how to do it well, and share that experience.
1-4 jibe with my experience.. that's why we built a SaaS cloud that allowed each customer (company, not individual users) to run a specific version of the platform, rather than the full multi-tenant model where everyone is on the same track. The latter may work for peripheral applications, but for core business apps it's a non-starter.
Unfortunately, it often felt that we were having to write everything from scratch; you can barely find anyone talking about this model, or any tools designed to handle it. Everyone seems to be either fully multi-tenant or manually launching individual servers (which is not feasible for low price SaaS).
We're in the same boat as you and our SAAS model involve custom deployment versions for each client. We're looking at trying to keep the databases unique per client, but handling the core requests in a multi-tenant environment, but it's difficult to plan ahead for all the different asks our customers need.
I often wish I worked at one of the SaaS product companies that target small-business.
I've considered that approach, but that means keeping the code fully retrocompatible, and that kinda leads to madness :D
Plus if you have different processes per client, you can provide better security, particularly in terms of leaking customer data to each other. In our case, we just used different Linux and Postgres users for each client, but even just that meant that a few security bugs discovered in the application couldn't be used to read/write data of other customers.
Even if people don't believe that all code over five years old is doomed, writing code to be easy to rewrite still seems like a useful idea. You're preserving optionality, you're making it easier to try out multiple designs, and you'll have an easier time recruiting collaborators because they'll have more fun projects to try, and so they'll be more likely to progress 'down the funnel' from using a project to hacking on it to contributing it all the way to taking over its running.