

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

Throwaway account, for obvious reasons.<p>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.<p>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.<p>In short, how can you accept ownership or responsibility for code that you don't have control over the quality or design of?
======
procrastitron
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.

------
WorkerBee
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.

------
d0m
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 :)

