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.
Firstly I'd like to point out that unit tests are not a replacement for integration tests. The two need to exist side-by-side. Be grateful that you have integration tests, otherwise one of your small refactorings could well make one of the low-tolerance cash cows go ballistic on you.
I would start to work on the compiler warnings and unused variables and imports. Get a clean build first. Then start to write unit tests to document the current behaviour, then start the real refactoring.
I can't really see any negative impact. You will gain a lot of deep understanding of the code base, which will help with bigger refactorings. It is almost always preferable to refactor than to rewrite, since during refactoring your still have a working product, whereas during the rewrite you don't. And in the end the sales of the product have to pay your salary.
Once the requirements are starting to come in, I would use what I call the spotlight approach. Do the usual agile thing (prioritize, then cut off a small slab for an iteration, and work through that) and leave quite a bit of time for code improvements. Then refactor where you are working anyway. Over time this will cover wide areas of the code base without you ever having to venture into areas where you would have difficulty justifying to management why you are working on that part of the code.
Best Answer
I can give you one example from my experience.
About 10 or 12 years ago I inherited an application from a team of developers that ended up leaving the company (too long to get into here...). The system was a large home-grown middleware report generation system. It ran every week night and generated about 2 dozen Excel reports for senior executives of a Fortune 500 company. When I inherited it, it took about 5-6 hours to run and during any given week would fail at least 2 nights.
I was not a happy camper to be given this mess.
Initially my plan was just to stop the bleeding and fix the main cause of the failures. After I became more comfortable with the code base, I started looking for places where I could refactor and add stability and performance. Over the course of 2 years or so, I made many, many changes to the system. We retired that system a couple of years ago and at that point the whole process took 45 minutes to run and hadn't generated any issues in years.
A lot of work went into paying down the technical debt but it was well, well worth it. It was nice not getting any phone calls in the middle of the night that the system failed. It was nice coming into the office in the monring and seeing nothing but good news in the logs.
(Aside... After a couple of years I ran into one of the main developers of this system. He asked me how it was doing and I told him how bad the system was. He actually apologized and told me he knew it would be a handful to support after he left and wished he had done a better job on it).