A Pragmatic Exploration of Tech Debt(markdrago.com)
markdrago.com
A Pragmatic Exploration of Tech Debt
http://markdrago.com/blog/2012/04/23/a-pragmatic-exploration-of-tech-debt/
3 comments
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.
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.
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.
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.
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.
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.
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.
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.