| > Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense. This really is NOT how you start an article. You only come across as needlessly assertive and arrogant. > Nobody explained technical debt; we assumed it was a fundamental property of the work. Total BS. Literally every manager I ever addressed in a sentence where "technical debt" was mentioned did question what exactly it is and why do we need to address and "repay" it. Where is the author of the article living? Not with us the programmers here on the ground, that's for sure. > Now, one major concern in academia is rigor. Ah, so now it's about academia and its definition. I'll cut him a deal. Bring your academics to my former customers and see if they can override management's idea of a technical debt. Succeed 5 times and then I'll bow to you and accept your definition. Until then you're just an annoyance like that guy on parties who is always going around telling people "well ACTUALLY you are using the wrong term". Doesn't matter what the dictionary says, people. It matters what most of the people think a word means. It matters what most of the people do when faced with the word. Why is this so hard to accept for many? -- No, I haven't read the entire article. It smells of intellectual elitism and arrogance a mile away. The author must work on his tone. Technical debt, whatever your definition of it is, is still a natural property of tight schedules. That's it. We can all go home now. I wouldn't expect an academic to understand realities of schedules and budgets though. |
My initial thought was that, as academics, they were going to be aloof and out of touch. However, as a boots on the ground dev who has worked from start up through multi-thousand employee public company, and who has held leadership roles, I agree with the article. Maybe if you read it, you would too.