
A Pragmatic Exploration of Tech Debt - markdrago
http://markdrago.com/blog/2012/04/23/a-pragmatic-exploration-of-tech-debt/
======
DanielBMarkham
This might be a good time to restate Markham's Rule of Technical Debt:
_Technical Debt can never be more than the value of the program to the user_

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.

~~~
eru
Why don't you call it the bankruptcy rule? It's similar to: Equity in a
limited liability company can never turn negative, since you can just let the
company go bust.

------
fleitz
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.

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.

------
swah
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.

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).

Searching somewhat it seems there aren't many posts describing
Rails/Django/PHP <-> Backend Service recipes.

~~~
crazygringo
Speaking as someone who is using SOA at a startup...

I think there's a lot of value in it, but I also think SOA is overkill for a
lot of projects. Plus, given the amount of pivoting that goes on with projects
at the beginning, you might wind up implementing a SOA in a totally wrong way.
It just seems like a lot of extra overhead. Plus, in many cases you can
gradually migrate your project later to a SOA, depending on where the
bottlenecks are.

