Can We Please Stop Talking About Tech Debt? • Emily Rosengren • GOTO 2023
contradictory report Emily talks about tech debt and suggests not to call the technical problems like this:) The argument is that since Ward Cunningham came up with this metaphor, our industry has changed. The very concept of Ward Cunningham was well described by Martin Fowler in his article.Technical debt": Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt. Emily appeals to the following changes: Transition from project work to product-oriented teams – we have invested in changing the approach to organizing teams to create software in a different format Distribution of cloud-native distributed systems - the area that can be attributed to debt has increased There's a whole technology zoo. (on 1992 The year the concept of tech debt appeared)
Emily then suggests that There is bad software and better software, but no such thing as "best" or "the right" implementation And from that comes the idea that Software and context around it is continually changing - the best tradeoffs come from current context
Further, the author of the report suggests not to hang the tech debt label on any technical tasks, but to influence the entire improvement of the product and she proposes such an algorithm in order to do this successfully:
- Do the work when it matters
- Explain the "why"
- Understand the product roadmap and care about it too
Next, she examines the standard thesis of engineers typeI can't get my tech debt prioritized" and proposes to reformulate this into a statement of a different kind"I can get my timely. prroduct-strategy-relevant improvement recommendations prioritized":)
P.S. In principle, the author’s thoughts are good, but it seems that this is just a name change, but not a conceptual change of approach. I much prefer John Osterhuth’s approach to strategic programming, as he described in A Philosophy of Software Design. (Here is a brief description of the book that we stripper Code of Architecture Club). Plus, I think we should make up-front technical investments in terms of introducing engineering practices into new projects, rather than waiting for debt accumulation and interest payments.
#Engineering #Architecture #Processes #Management #Leadership