When I met with my boss to discuss this, he said I should include refactoring in all my estimates. He said it's not a problem he wants to think about. Instead, I should handle it.
This isn't a problem that management in general wants to think about. They aren't the engineers, you are. Just make this an unspoken part of all of your estimates, and you'll find that the technical debt decreases.
It will never be perfect though. Technical debt, like credit card debt, is an investment in getting customers faster and gaining market share over your competitors faster. Like credit, if managed properly, it can make you quite successful.
I think we must make a difference between code ownership:
- from the responsibility point of view,
- from the code style/hacks etc. point of view.
The first one must be encouraged. If nobody is responsible for low quality code and bugs, bad things will happen. It doesn't mean that the bug related to your own code must be assigned every time to you: if the code is correctly written, anybody can fix the bug in any part of the code. But if you don't have any feedback about the bugs you do, you'll produce the same bugs again and again.
Code ownership may help a lot both the managers and the developers, especially the developers. If I know that 80% of bugs in the product were in my code while we were three developers working on the project, and that 75% of those bugs were related to SQL Injection, I would be more careful writing code the next time, and make an extra effort to write database queries correctly.
The second one (code ownership from the code style/hacks, etc.) is mostly a bad thing. What does it bring to the product? It does not increase the quality of the product, but decreases the uniformity of the source code and makes it difficult to maintain it lately.
For many large projects, people don't stay for life working on the same piece of code. And here, I don't even talk about horrible things like the developer being hit by a bus: I don't think code ownership is the first concern in this case. But lots of minor thinks happen: people migrate from development to management or other jobs, or choose other projects, or work on other stuff, or start using another language (if several languages are used inside a project), etc.
A piece of code of a project can also be reused in another project, and the developer working on this other project would like to modify some parts of the code to fit the new needs, without asking for advice the former writer of the code.
Is it a code smell? Well, it depends on what do you mean by code smell. For me, it's all about the overall coherence of the project and correct management. In a good project,
- code style guidelines are enforced to help to understand the code easier later,
- more experienced developers do not violate the KISS principle, thus helping the understanding of the source code later by the less experienced colleagues.
To conclude, code ownership must be tracked through version control, but you must not be able to say that a piece of code is written by you or somebody else in a team.
Best Answer
Since I didn't get a true answer to my question I though I'd follow up with what I did.
I ended up putting together a combination of a Due Diligence Checklist and a Software Quality Assessment in a combined document along with a list of questions and answers received from the various communications with the company we were buying the product from.
For the Software Quality Assessment I used a variant of the ISO/IEC 9126 standard tailoring it to our internal needs and weightings. This covers key aspects of software including maintainability, evolvability, portability and descriptiveness.
The due diligence checklist had a list of activities along with whether they had been completed and comments on how the activity was done. Activities included the following:
Software Architecture
Hardware Architecture
Support
Build and Deploy
Cost Estimates