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