4 ms·

Sure, but are you differentiating between run of the mill bitching, and actual serious concerns? Because if I whine about x internal library in stand up, that i

by fhood 8y ago

Sure, but are you differentiating between run of the mill bitching, and actual serious concerns? Because if I whine about x internal library in stand up, that is probably not important. But if I come to you in person and tell you that x internal library is introducing more bugs than saving time, I probably really mean/am concerned by that.

Fire-Dragon-DoL 8y ago
Freshly written code can easily be technical debt. An example of this could be "put a junior in a comolex piece of code and let him add a feature". That feature will work and probably is technical debt, because of bad design choices. I've been on the other side of this. I was developing the frontend part to a series of http endpoints and my colleague was working on the http endpoints. He was creating some terrible code but I had no power at the time. When he was done, the code was functional, had various bug and a new feature was needed. I spent a week studying the code and managed to add a feature, which however was buggy due to how the code was written originally. I fixed all the bugs, and ended up totalling 4 weeks of work. This colleague was let go after this due to a series of circumstances, so I became the owner of the code. Then a new feature needed to be added but to do that i'd need to change various things in such code. Two weeks in, I still wasn't done. At some point I asked to be able to rewrite the code. I did, it took 2 weeks and was able to add the feature easily. I'm no genius but code that cripples you down from the get-go is tech debt. Tech debt is failure in software design, which ends up in unmaintainable code. I'd listen to anyone pointing at tech debt in my code, it means my code sucks, I made a big professional mistake and I need to correct it. There is also voluntarily added tech debt, that's the one added by taking shortcuts. As long as you don't build new features on top of it, you are good.

by fhood 8y ago

Fire-Dragon-DoL 8y ago

Freshly written code can easily be technical debt. An example of this could be "put a junior in a comolex piece of code and let him add a feature". That feature will work and probably is technical debt, because of bad design choices. I've been on the other side of this. I was developing the frontend part to a series of http endpoints and my colleague was working on the http endpoints. He was creating some terrible code but I had no power at the time. When he was done, the code was functional, had various bug and a new feature was needed. I spent a week studying the code and managed to add a feature, which however was buggy due to how the code was written originally. I fixed all the bugs, and ended up totalling 4 weeks of work. This colleague was let go after this due to a series of circumstances, so I became the owner of the code. Then a new feature needed to be added but to do that i'd need to change various things in such code. Two weeks in, I still wasn't done. At some point I asked to be able to rewrite the code. I did, it took 2 weeks and was able to add the feature easily. I'm no genius but code that cripples you down from the get-go is tech debt. Tech debt is failure in software design, which ends up in unmaintainable code. I'd listen to anyone pointing at tech debt in my code, it means my code sucks, I made a big professional mistake and I need to correct it. There is also voluntarily added tech debt, that's the one added by taking shortcuts. As long as you don't build new features on top of it, you are good.