[ebiester]

I don't understand this.

If you build a system for resilience, it should not take significant effort to maintain. You should be able to keep the lights on with 10-20% of the engineering team. The rest is growth.

Growth may be making the product better, creating new product lines, or improving the scalability - for example, allowing larger numbers of users or entries. However, you can make the choice to make a well constrained product that serves a valuable use but doesn't need growth. Consider Bingo Card Creator, for example.

[lamontcg]

> If you build a system for resilience, it should not take significant effort to maintain. You should be able to keep the lights on with 10-20% of the engineering team. The rest is growth.

After 10+ years you always see the operational demand increase because of all the necessary edge conditions you build up (backcompat and whatever else).

[ebiester]

Does the cost of change increase, or the cost of maintenance, or the cost of keeping it on?

Yes, the cost of change by definition increases with the complexity. I don't think that is in contention. Why is it changing for any other reason that you're growing (or trying to stave off decline?) For internal tools, change may be a function of external business pressures (like a supplier going out of business, requiring changes in an internal tool), but that is asking for new software.

As you add libraries, the cost of maintenance increases because the surface area of security increases. However, short of major changes (React, Rails, Etc), this feels like it's not moving outside the 10-20% range.

Then, there's the cost of keeping it on.