My current idea of handling technical debt is to keep track of how much resources it actually consumes and then make decisions.

Trying to rewrite everything in a new, shiny way leads nowhere. The warts and hacks of the old code may well be there for a reason, and you can't learn all the corner cases by just staring at the code. Which means that the new system will be just as buggy and just as hacked and full of suboptimal decisions because of time pressure. Been there, done that.

Trying to swallow your pride and get the job done leads nowhere. It hurts one as a professional and leads to passive aggression building up. In the worst case you only earn gastritis or angina.

Proposing changes and steering the discussion is a good thing. If that's not encouraged by management or ignored by colleagues, that's a bad sign about the workplace as a whole. But even if they do embrace the discussion, it's a long way to go and you get 80% of all proposals turned down. That's an uphill battle, and it has to be fought.

Writing comments that explain the legacy stuff and the reason it's done in this way is a good thing. As knowledge accumulates, it may become obvious how to clean things up without breaking them or starting from scratch.

Taking care to not break the work of others is a good thing. Even the best and shiniest API change shouldn't ruin the team's Friday night. Deprecate things gradually. If a better function cannot be trivially wrapped to emulate a worse function, it's not yet better in the first place.

Sometimes a rewrite has to be done. But it must be justified by evidence and sanctioned by the team and the business guys. Like, we wasted X money because of bugs and downtime and development of new system to this spec is Y money and Y < X.

That's my opinion. It's changing over time. I'm still learning.

In reply to Re: Code Structure Changes by Dallaylaen
in thread Code Structure Changes by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.