technical debt - is it something observed from another person
-
I can't get my head around how one can avoid technical debt, because I think now it only something created after the fact. consider making a new product: I, ME, wants to make version B of the product, because it will be better, meaning less "technical debt" (being bugs, and code short cuts, which will need refactoring to make for performance or means to expand features in future) but I need to make version A to get to version B. Sure with experience, version A might be closer to B, but this "inferior" version will still exist. With unlimited resources we could make version A a prototype, but practically A allows for generating some revenue to cover the starting costs. Now from an outside viewer, they have the benefit of observation and can point out some technical debts that will be incurred. but that outside viewer can also be your self, after making version A, and taking a step back to observe and go ah, yeah, this would be better if changed. You go buy something with credit, you can see what the debt will be BEFORE accepting. But can technical debt be observed before hand? Not include the, well well go with Option 1 now, and transition to 2 next year. You have already created what Option 1 is, thus in the stage of observing. not sure what the point is, kind just felt like when someone new comes into a team, and first thing they start mentioning is technical debt this and that, and like, yeah, no shit, its easy to critique after the fact, how the projects you made before coming here looking.
Technical "debt" implies something that has to be paid back. If something is hard to maintain, say so. Doesn't mean it has to be fixed or rewritten. A user can also relate better to an outstanding "bug" report than "technical debt" ("Is he going to fix things or what?")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I can't get my head around how one can avoid technical debt, because I think now it only something created after the fact. consider making a new product: I, ME, wants to make version B of the product, because it will be better, meaning less "technical debt" (being bugs, and code short cuts, which will need refactoring to make for performance or means to expand features in future) but I need to make version A to get to version B. Sure with experience, version A might be closer to B, but this "inferior" version will still exist. With unlimited resources we could make version A a prototype, but practically A allows for generating some revenue to cover the starting costs. Now from an outside viewer, they have the benefit of observation and can point out some technical debts that will be incurred. but that outside viewer can also be your self, after making version A, and taking a step back to observe and go ah, yeah, this would be better if changed. You go buy something with credit, you can see what the debt will be BEFORE accepting. But can technical debt be observed before hand? Not include the, well well go with Option 1 now, and transition to 2 next year. You have already created what Option 1 is, thus in the stage of observing. not sure what the point is, kind just felt like when someone new comes into a team, and first thing they start mentioning is technical debt this and that, and like, yeah, no shit, its easy to critique after the fact, how the projects you made before coming here looking.
the debt must be paid back in some way by somebody. I will escape it by changing a new job :)
diligent hands rule....
-
I wrote an article that touches on a lot of what you said: The Software Rewrite[^].
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
I wrote an article that touches on a lot of what you said: The Software Rewrite[^].
I can highly recommend that article. Particularly the advice to refer to a proposed re-write as "re-engineering" to avoid scaring people.
-
the debt must be paid back in some way by somebody. I will escape it by changing a new job :)
diligent hands rule....
Southmountain wrote:
I will escape it by changing a new job :)
The new way of doing friends... :rolleyes: :-D :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
If you look at the books on software engineering, the thing is that once you reach a level of code and have tested enough with test driven programming and the new devops.. and not to forget documentation and the new buzz words like continuous improvements over the air etc... your product will always be indebted to the people keeping it running.... no more gold master disks and iso's But can technical debt be observed before hand ? You have metrics for that in software development ? and you as a program manager need to keep track of such things if so... (google ...[How to Reduce Technical Debt in Your Software Development Project?](https://www.resourcifi.com/blog/reduce-technical-debt/) its usual when a new person comes into a existing project..first think he would like to do is runway..just like the rest of us...
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
Indeed - possibly the most famous work, the mythical man month, basically says you should plan on throwing one away, but also warns of the second system effect, where you cram in all the things you had to leave out of the first.
-
Technical debt is the term applied to deferring a proper fix that will take lots of time and resources, instead performing a technically inferior fix that can be done quickly and cheaply. It is most often incurred during bug fixes / maintenance, not during design of the original product. It is sometimes required when a product version must be out ASAP, (e.g. when a client is expecting a fix) and is always put in with the intention of fixing the bug properly "later". In some cases, a "quick and dirty" product will be produced with the intention of revising it in a later version. This usually happens when the product must be demonstrated by a particular date (e.g. for a show, upper management, etc.). Often this "quick and dirty" solution will then be released to customers. From the engineering perspective, all forms of technical debt are bad. From that cash flow perspective, having some income from an inferior (but working) product is better than having no income from a better product.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Releasing an inferior product to your most important launch customers is a recipe for product failure. When managers ask engineers to cobble something together, they generally imagine that you will produce perfect, customer pleasing code faster than you otherwise would because they asked you using whatever words make the engineers acquiesce. It's a form of magical thinking. Now you have bad code in the field that must be supported first, before engineering can produce a properly working solution, and your launch customers are dissatisfied with your bodged-together prototype. Customers will ask for the important features you left out, so engineering will be under pressure to rush those features into production, resulting in an inferior product that is bigger and harder to maintain that must be supported before you can produce a properly working solution. This is technical debt.
-
Releasing an inferior product to your most important launch customers is a recipe for product failure. When managers ask engineers to cobble something together, they generally imagine that you will produce perfect, customer pleasing code faster than you otherwise would because they asked you using whatever words make the engineers acquiesce. It's a form of magical thinking. Now you have bad code in the field that must be supported first, before engineering can produce a properly working solution, and your launch customers are dissatisfied with your bodged-together prototype. Customers will ask for the important features you left out, so engineering will be under pressure to rush those features into production, resulting in an inferior product that is bigger and harder to maintain that must be supported before you can produce a properly working solution. This is technical debt.
Technical debt is always a bad idea from the Engineering point of view, and usually from the Management point of view as well. The only case where it might be justified (again, by Management, not by Engineering) is when money is running out, and having something to put on the market is seen as better than having nothing. The gamble here is that the time (and money) bought by the inferior version might allow the company to release the better version. Note that Combat Damage Control on a Naval ship works in a similar manner - get things working NOW, and do a proper fix when there is time. The Captain would definitely not want to sideline the ship in mid-battle to make proper repairs; by the time they are finished, the battle may be lost. The problem is that this reasoning is used for less-defensible cases, such as releasing a product in time for a show, or releasing it in time for it to affect the annual bonuses of those in charge of the product.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Technical debt is always a bad idea from the Engineering point of view, and usually from the Management point of view as well. The only case where it might be justified (again, by Management, not by Engineering) is when money is running out, and having something to put on the market is seen as better than having nothing. The gamble here is that the time (and money) bought by the inferior version might allow the company to release the better version. Note that Combat Damage Control on a Naval ship works in a similar manner - get things working NOW, and do a proper fix when there is time. The Captain would definitely not want to sideline the ship in mid-battle to make proper repairs; by the time they are finished, the battle may be lost. The problem is that this reasoning is used for less-defensible cases, such as releasing a product in time for a show, or releasing it in time for it to affect the annual bonuses of those in charge of the product.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
The goal of combat damage control in naval warfare is to preserve the ship until it can be refit. The problem with comparing incurring technical debt to damage control is that in business, the battle never ends; there is no down time during which to reduce any accumulated technical debt. Startups may think they're being smart by allowing technical debt to accumulate, but IMHO this is an illusion. What happens is that they can remain in business for a few extra months, but their software development effort cannot scale due to the technical debt. They simply flame out later, having eaten through additional investor cash. As an investor I would be wary of any CEO who chose to accumulate technical debt.
-
Technical debt is the term applied to deferring a proper fix that will take lots of time and resources, instead performing a technically inferior fix that can be done quickly and cheaply. It is most often incurred during bug fixes / maintenance, not during design of the original product. It is sometimes required when a product version must be out ASAP, (e.g. when a client is expecting a fix) and is always put in with the intention of fixing the bug properly "later". In some cases, a "quick and dirty" product will be produced with the intention of revising it in a later version. This usually happens when the product must be demonstrated by a particular date (e.g. for a show, upper management, etc.). Often this "quick and dirty" solution will then be released to customers. From the engineering perspective, all forms of technical debt are bad. From that cash flow perspective, having some income from an inferior (but working) product is better than having no income from a better product.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Finally, I understand what that is. I kinda imagined it as something clever that was done and becomes too complicated for future generations to expand on. But what you described is a hack, a kludge...that usually lacks any elegance and so one day has to be refined. (sigh) Yeah, many videogames have their storied hacks, but if it's a one time, it doesn't matter, otherwise the next use of the 'engine' will replace the hack or kludge...hopefully.
-
I can't get my head around how one can avoid technical debt, because I think now it only something created after the fact. consider making a new product: I, ME, wants to make version B of the product, because it will be better, meaning less "technical debt" (being bugs, and code short cuts, which will need refactoring to make for performance or means to expand features in future) but I need to make version A to get to version B. Sure with experience, version A might be closer to B, but this "inferior" version will still exist. With unlimited resources we could make version A a prototype, but practically A allows for generating some revenue to cover the starting costs. Now from an outside viewer, they have the benefit of observation and can point out some technical debts that will be incurred. but that outside viewer can also be your self, after making version A, and taking a step back to observe and go ah, yeah, this would be better if changed. You go buy something with credit, you can see what the debt will be BEFORE accepting. But can technical debt be observed before hand? Not include the, well well go with Option 1 now, and transition to 2 next year. You have already created what Option 1 is, thus in the stage of observing. not sure what the point is, kind just felt like when someone new comes into a team, and first thing they start mentioning is technical debt this and that, and like, yeah, no shit, its easy to critique after the fact, how the projects you made before coming here looking.
I will use some current technical debt. PostgreSQL is an awesome DB system. But early on, they decided to use FORK() [processes] over threads. It made a lot of things easier. Now the hard part is that threads are smaller, lighter and don't need as much initialization. But they also don't work the same. So, if you have a parallel query, they are FORKING a process, with all that baggage, because it's the easiest thing to do. But now the number of DB connections become constrained more before you run out of resources. And what makes it a great example. To change this to use Threads would be a gigantic rewrite, with a lot of inherent risk and expense. Other tools show up (pgBouncer) to do session pooling, etc. So you can push this off for a future day. One that may never arrive! Times change, and older software shows it's age. Also, I think OpenSource is the right model to view Technical Debt through. If you can add a feature that you are NOT getting paid to add, and there are 2 approaches to handling it. One with obvious technical debt, and the other approach that would take you so much longer that you would abandon the original project over... There's you choice. Now, you can sale both of those options inward towards each other. And the purpose of the community and the maintainers is to pick a reasonable level of limiting the accumulation of Technical Debt. I believe PG does this pretty well, although I have heard many complain that they will NEVER bother submitting anything because it's just such a long, drawn out, and painful process... And even after jumping through the hoops, the code may never be accepted. I believe the Point Martin Fowler made was: There is always a level of Technical Debt... And we can choose to build our software in ways that allows us to address it safely! (TDD, etc). He was using this as the Iron Man for test-driven development... And why testing adds confidence, which increases developer productivity. I think he would chuckle at 100% debt-free code as the goal. Like PG. When will we see the debts? (mostly when things change, or the software becomes WILDLY popular)
