3 ms·

I agree wholeheartedly. Sadly, good performances are impossible to maintain for the code-base I am working on. After years of very fast iterations without opt

I agree wholeheartedly. Sadly, good performances are impossible to maintain for the code-base I am working on. After years of very fast iterations without optimizations (or even good architecture) and with a product team pushing for even more new features at an accelerated rate, the technical debt is spiraling out of control.. I am not sure of what can ben done in these conditions. After 18 months in that company, I will very probably move on to another job soonish for many reasons, leaving mostly inexperienced engineers in my team, ready to reproduce even more mistakes.

klibertp 12y ago
> I am not sure of what can ben done in these conditions Well, I'd say you are on a right track here: > I will very probably move on to another job ;-) On a more serious note, it's important to a) have a plan for dealing with technical debt prepared beforehand and b) communicate clearly about what is caused by the unpaid debt. At some point the decision makers will want you to tell them what you can do about it, which is when you present a), and hopefully get enough time and budget to fix at least some of the most glaring problems. The only other option for a project - if you know there won't be any decision to deal with technical debt - is to fail. In which case moving on is the best course of action.
- on_and_off 12y ago
  hahaha, yeah sadly it seems to be the reasonable choice. I have demonstrated an enormous memory leak in our app (not really difficult to do when you look for it with the tools provided by the sdk). I have explained why it happens (shitty architecture is shitty) and proposed to prototype alternatives. It was 8 months ago, no time to do it (for me or anybody else in the team), we have features to add. Meanwhile, OutOfMemoryException is our main cause of crashes. Sigh.

3 ms·

I agree wholeheartedly. Sadly, good performances are impossible to maintain for the code-base I am working on. After years of very fast iterations without opt

by on_and_off 12y ago

klibertp 12y ago
> I am not sure of what can ben done in these conditions Well, I'd say you are on a right track here: > I will very probably move on to another job ;-) On a more serious note, it's important to a) have a plan for dealing with technical debt prepared beforehand and b) communicate clearly about what is caused by the unpaid debt. At some point the decision makers will want you to tell them what you can do about it, which is when you present a), and hopefully get enough time and budget to fix at least some of the most glaring problems. The only other option for a project - if you know there won't be any decision to deal with technical debt - is to fail. In which case moving on is the best course of action.
- on_and_off 12y ago
  hahaha, yeah sadly it seems to be the reasonable choice. I have demonstrated an enormous memory leak in our app (not really difficult to do when you look for it with the tools provided by the sdk). I have explained why it happens (shitty architecture is shitty) and proposed to prototype alternatives. It was 8 months ago, no time to do it (for me or anybody else in the team), we have features to add. Meanwhile, OutOfMemoryException is our main cause of crashes. Sigh.