Ask HN: How can you "own" code without control over it's quality or design? | Hacker News Reader

Ask HN: How can you "own" code without control over it's quality or design?

2 pointscodeowner3 comments

Throwaway account, for obvious reasons.

We've been told in our project that we should "take ownership" of some extremely bad code that I have been hacking away at for several months, fixing and finding bugs in the spaghetti. Any attempts to refactor the code gets rejected by management (unless we do it secretly; they have damanded "no secret development") and any new implementation ideas appear to require full working prototypes, a cost analysis and a proposal document before being considered. Of course, we are never budgeted the time to do this. The result is that we are now getting blamed for the results of bad design decisions made many years ago before we even started on this project.

I'm a developer in my 20s (but with several successful projects behind me) so I'm hoping some old HN hands have managed to deal with this problem before and can offer some advice to me and other people stuck in this situation.

In short, how can you accept ownership or responsibility for code that you don't have control over the quality or design of?

You might be surprised at how large an impact adding unit tests can have on existing code. It makes it feasible to start incrementally fixing the spaghetti while having some assurance that you aren't breaking existing functionality. Granted, it's not a panacea, but it does have a huge impact.

That all being said, the concept of "taking ownership" without having any control of how you do your job is bullshit. The only way to solve that problem is to tell management that they are solely to blame, but the solution you get may be to no longer work for them; you have to decide for yourself if it's worth the risk.

You can't successfully own code that you don't control.

I believe that the best outcome for both of you would be 20% of time set aside for refactoring and increasing test coverage. Sure you'd want more but features have to roll out too. Management may not realise that refactoring that much is necessary.

You may have to pad out estimates of new work, and say things like "in order to do that we'd have to understand the guts of the foo subsystem, and make sure that we don't break it while we change it, so we'll have to put tests around it while we change the code" while mentally adding a week's time refactoring and adding unit test coverage to foo to your estimate. Grease the moving parts - things that change once tend to change again, and you'll be happier the second time around.

If you can't even do that, ask them what they mean by "take ownership". Maybe they just want you to the go-to-guy for that particular monster. Say what would do if you really owned it. If you are completely overruled, you may have to be blunt and point out that this is not ownership in any non-bullshit sense.

If that fails, as the wise man said: if you can't change your company, change your company.

Take the time to make new stuff as good as you can possibly can and try to make old stuff as usable as you can possibly can.

Even thought they say you now "own" the code, they perfectly know that you haven't coded it. So you can't be taken responsible for bugs that appears in code you don't even know.

Maybe you should work in a startup and be happy instead :)

Reply on news.ycombinator.com