A Pragmatic Exploration of Tech Debt

This might be a good time to restate Markham's Rule of Technical Debt: <i>Technical Debt can never be more than the value of the program to the user</i><p>Sure, it might cost a million bucks to rewrite all that bad code. But if the program only provides enough value to some user somewhere to be worth ten dollars, you can never have more than ten dollars worth of technical debt associated with it, no matter what it looks like.

Just as most people borrow to buy their first home tech debt can be good to take on knowingly in a lot of circumstances. As long as the debt is being used to finance higher returns it's a very good idea.<p>For a new venture it can reduce risk and bring advantages such as time to market. PHP is a major tech debt for most organizations, but it was probably worth it for Facebook.

Currently I have the feeling that successfull companies are mostly using SOA architectures, but startups/individuals are writing their whole apps with Django/Flask/Rails/Play.<p>What would have to change so that those architectures were the obvious way to write an app in the first place? (One could argue they never are the proper way).<p>Searching somewhat it seems there aren't many posts describing Rails/Django/PHP &#60;-&#62; Backend Service recipes.