Ok, I'll try to find some Ward Cunningham's work. ---- > Technical debt is precisely the mismatch between the language you are programming in, and the domain

Ok, I'll try to find some Ward Cunningham's work. ---- > Technical debt is precisely the mismatch between the language you are programming in, and the domain you are programming for. That's a concept on a very different level from > the lack of understanding of what the client wanted (often the ignorance of the client himself of what he actually wanted) And the term "technical debt" seems to be a very bad name for either of those. Just look at the examples the others provided : the word 'technical' makes one think that it's an issue with tool (= codebase) maintenance first ! ---- > semantically, you get to define your own classes and methods and create your own little world inside that language, where things can be combined and chained together That is if you're even using OOP in the first place. I'm now viewing it with suspicion, especially after the only course we had on it, in Java, where we weren't even warned about things like "Composition over Inheritance". (Ok, we also had a half-course on UML.) OOP seems to me more like a tool that should only applied to specific problems : for instance making a GUI (I have some Python-Qt experience). In the same way, I do see programming languages themselves as more or less fitting to certain problems. Speaking of which, this semester I had to pick between C+ (C++ with a minimum of libraries, and god forbid, no OOP) and Fortran, and I picked C+ because Linux is mostly written in C. And hopefully one can find a language where you can keep the "impedance mismatch" between the language and the problem to a minimum. But for that you have to figure out what the problem actually is in the first place, which might take several design cycles ! But I'll try to read up on this "aspect-oriented programming".