Thanks for not taking umbrage as so many do. I'd argue that duplicate code falls under unfinished work; in the project in question the inefficiencies were astounding; there was one case I will never forget that fetched over 100,000 rows to eventually get a primary key that had been passed into the function. Dozens of lines, none of it necessary. People just kept piling more atop what was already there instead of reading the code.
Nomenclature is a peeve of mine; I'm a little obsessive-compulsive about accuracy in expression and in software development it's all moving in the wrong direction. I find "stories" to be infantilizing (where're the milk and cookies?) and walked out of a meeting once because I was going to blow up. Refactoring never means the same thing twice.
But back to the topic. Reading code is actually what we spend more time doing than everything else combined, except, for some poor wretches, attending meetings (my first group at Microsoft had one meeting per week in 1989). Yet hardly anyone does a smidgeon of work to make code legible. Most of the code I've had to read was practically obfuscated. For example if there is a long stream of lines assigning values to the members of a struct or class instance we will see
name.lvalue = rvalue;
and since the lvalues are all different lengths there is no vertical alignment; a tiny bit of extra work aligns all the assignment operators and then the rvalues are aligned too. This looks like a table and we have well-honed reflexes for reading tables. People look at my code and agree it's very easy to read and then go on to say, usually through clenched teeth, that they aren't going to write like that.
So it's no wonder the people just charge ahead and write from scratch code that is already in the project a dozen times; reading code, our foremost activity, is just too damned difficult because it's pretty much illegible.
When it comes to clean code and sanitary codebases, I think that's where we need to start.