I started to answer the other question about technical debt. Then I realized that this question was more interesting to me.<p>How did you frame the argument that convinced the non-technical decision makers that technical debt should be taken care of? Was the metaphor of "technical debt" a good way to frame the argument, or was the notion too ethereal?
I'm not sure that I've successfully convinced the decision maker, but I did work on a project where everything was put on hold to take time to pay the technical debt.<p>As a junior engineer, I was brought in to upgrade a test facility that was undocumented. In the first design review, I said "I have documentation up to <i>this</i> point and after that we're guessing." A much more senior engineer, who had been in charge of the test facility for over a decade, took great personal offense to that and told my manager I didn't know what I was talking about. So, I was told to proceed.<p>About 6 weeks later when we had everything built and started running through the test procedure, we blew up a $40K piece of equipment. Then, my manager stopped everything and told me to reverse engineer the test facility and update the drawings. Turns out, there were some wires spliced together that weren't captured in the area of the test facility where I said that we were guessing.<p>I think that sometimes non-technical decision makers sometimes having trouble seeing the technical debt, so if you can make them feel the pain of the debt, either in cost or schedule, it makes it much more real to them.