21–30 of 32 posts
The biggest thing I think people need to know about technical debt is that it must be used to create growth. Consider the situation where you go to the bank and ask for a loan. You tell the loan manager that you will spend the money on pizza parties. Unless you are in the pizza business, you are unlikely to secure the loan. Loan managers want to know how you are going to use the money you gain to generate growth and…
Earlier quoted context omitted.
It's great to able to articulate that, but in the real world this sort of thinking does not actually hold much weight. Launching a month early is a good thing.
not necessary. if you launch early a crappy feature with a ton of problems it is actually very harmful. time to market is just one dimension of a trade offs you need to balance if you want to succeed
For example, I've found that anything related to the general architecture of your app is very important and you should almost never cut corners in those areas - This includes decisions related to what framework you will use, the structure of your URLs/links, how your app will use/reuse components, database engines, etc... These are fundamental engineering decisions and if you rush those, you will likely suffer for many years.
On the other hand, I found that it's generally OK to hack together the contents/features of individual pages within an app - If you mess up one page, you can always rewrite it fairly quickly.
Software is like a tree - If some of the leaves become diseased and start falling off - That's OK; so long as the tree's trunk is healthy and sturdy, the leaves can grow back quickly. If the trunk is rotten and the whole tree falls down - You will have to start again from scratch... If it doesn't crush you on the way down.
Earlier quoted context omitted.
Sure, except when your architect has some sort of contention, whether it's time, patience, or ego. Last time I had a decent idea to pitch, I pitched it to the architect twice - first time, it got completely thrown down. Second time, practically same pitch, except it was approved. I genuinely feel like a month was lost because of that. There's something to be said for "just doing it", and so so many times have archite…
It is both fortunate and unfortunate that there is a conflict of interest between entrepreneur and architect. As an entrepreneur, your job is to make money. The product is actually secondary. Risk is totally acceptable because you can start 20 companies and as long as 1 of them makes a huge payback, you are in the black. Architects, on the other hand make products. I once was interviewed by a firm that asked me a poi…
The question about what you did to stop a failing project is an odd one and probably completely ineffective. If that's the reason they didn't hire you, take it as a good thing. There's too much nuance for it to be considered useful without other considerations. My recent situation was that I pushed too hard to stop a failing project and was socially cast out. By the time the senior staff noticed that my suggestions actually made sense and weren't batshit extreme, the social dynamic was too much and I left.
On your last point, I'm not sure that would be a useful question, either. It's so incredibly for a linux lead to say, "Our infrastructure security has no technical debt", for example. It's easy to say, but impossible to prove without being at the company for a while, even for an in-the-mud admin. Hell, that's what happened at the place I just left.
Earlier quoted context omitted.
What happens when the architect doesn't have the luxury of pushing back? As in, the business will make the architect's boss bend over if the architect says no?
Ed Yourdan summed it up very well in one of his books. I don't actually remember which one, so I will try to summarize it, but the quote is worth looking up. If you think that the project you are going to work on will fail; if you think that the work you are doing is crap; vote with your feet. Your time is precious to you. You only have so many years in industry to work on interesting projects. Don't waste them. But…
It's true that software budget estimations are by their nature educated guesses at best. But we should still make an effort to be honest about them.
The biggest thing I think people need to know about technical debt is that it must be used to create growth. Consider the situation where you go to the bank and ask for a loan. You tell the loan manager that you will spend the money on pizza parties. Unless you are in the pizza business, you are unlikely to secure the loan. Loan managers want to know how you are going to use the money you gain to generate growth and…
I don't disagree with the gist of your comment but time to market is generally massively undervalued (and particularly by technical folk). It's more often than not a great reason for taking on tech debt (not to mention that early releases also constrain scope to smaller chunks).
The dynamics of getting to market are complicated and I don't agree that tech folk undermine them to any special degree. If you're an engineer with a few years experience, chances are you've been smacked by being too conservative or too loose with tech debt. Good contextual use of debt is a key part of the "senior" in any senior engineer. I'm happy to be "sloppy" and fast at the right moments.
My experience has been that business people value time to market, but only if they can offload the costs to engineering by taking on tech debt. When asked to put their money where their mouth is and pay for more engineers or cut scope, often the business side will balk. It's an annoyance when non-technical leadership perennially sees tech debt as a way to get a free lunch. Ain't no free lunches.
The best way I learned to deal with technical debt is to package it into securitized collateral debt obligations and find a product manager who can structure them into traunches and then find a QA manager who can rate these traunches and set up a regulatory framework with in which project managers can provide liquidity necessary to deal with it. If that does not work try to find an executive who can issue an Asset ba…
The biggest thing I think people need to know about technical debt is that it must be used to create growth. Consider the situation where you go to the bank and ask for a loan. You tell the loan manager that you will spend the money on pizza parties. Unless you are in the pizza business, you are unlikely to secure the loan. Loan managers want to know how you are going to use the money you gain to generate growth and…
What happens when the architect doesn't have the luxury of pushing back? As in, the business will make the architect's boss bend over if the architect says no?
Usually the technical debt will accumulate to the point the product can no longer move, is stuck on an outdated stack, and dies.