6 ms·

Notes on Modifying Unowned Code (2021)

29 points by luu 4y ago

woleium 4y ago
Wherever I've worked there is no such thing as unowned code. We all know it exists in theory, but as soon as you can't find the owner it's automatically yours.
- teddyh 4y ago
  …thus making sure that absolutely nobody goes around looking for unowned code? And, if they do find it, try to keep it a secret as much as possible?
  - woleium 4y ago
    Indeed. I didn't design the system, just experienced it :/
puyoxyz 4y ago
I’m surprised something didn’t go horribly wrong after deleting the unused code
- dopidopHN 4y ago
  Yeah that part I would be weary of.
charles_f 4y ago
> There are no tests The perfect example for why tests are a professional courtesy. Code is never yours, it belongs to the person who will maintain it when you are gone. Not adding tests is making their task risky and painful, it's just disrespectful.
hyperman1 4y ago
There are a few big assumptions in here, that in less-than-optimal companies require time-eating validation: * The source you have corresponds to whatever runs on production. No, you don't get access. * The source code has a clear, unique home ('here is a stack of DVDs with the full content of the last person's hard disk. No idea if someone else touched it and dropped it in some repo') * The source code compiles and runs locally. And doesn't damage production when you start it up because some monkey left a password in there. And doesn't shit all over your hard drive as said monkey expected a very specific folder structure on his personal laptop. * There is basic test infrastructure. Adding a very first test to an untested code base can take forever My experience is that most of this is OK when the software was developed internally. Internal people keep the nest clean enough, as they know they'll have to deal with the long-term consequences. When some random contractor or third party did a fly-by code drop('IT was too slow so business department X decided to hire someone themselves'), fear for your sanity.
ternaus 4y ago
I have heard a story about developer who deleted all the code in the company that was not covered with tests. Everything stopped working. His changes were reverted back. But within a month all code base was covered with tests.
- vultour 4y ago
  I don't see how one leads to the other. The only outcome of this should be immediate termination.
  - weard_beard 4y ago
    Everything did, indeed, terminate.

29 points by luu 4y ago

Wherever I've worked there is no such thing as unowned code. We all know it exists in theory, but as soon as you can't find the owner it's automatically yours.

teddyh 4y ago
…thus making sure that absolutely nobody goes around looking for unowned code? And, if they do find it, try to keep it a secret as much as possible?
- woleium 4y ago
  Indeed. I didn't design the system, just experienced it :/

puyoxyz 4y ago

I’m surprised something didn’t go horribly wrong after deleting the unused code

dopidopHN 4y ago
Yeah that part I would be weary of.

charles_f 4y ago

> There are no tests The perfect example for why tests are a professional courtesy. Code is never yours, it belongs to the person who will maintain it when you are gone. Not adding tests is making their task risky and painful, it's just disrespectful.

hyperman1 4y ago

There are a few big assumptions in here, that in less-than-optimal companies require time-eating validation: * The source you have corresponds to whatever runs on production. No, you don't get access. * The source code has a clear, unique home ('here is a stack of DVDs with the full content of the last person's hard disk. No idea if someone else touched it and dropped it in some repo') * The source code compiles and runs locally. And doesn't damage production when you start it up because some monkey left a password in there. And doesn't shit all over your hard drive as said monkey expected a very specific folder structure on his personal laptop. * There is basic test infrastructure. Adding a very first test to an untested code base can take forever My experience is that most of this is OK when the software was developed internally. Internal people keep the nest clean enough, as they know they'll have to deal with the long-term consequences. When some random contractor or third party did a fly-by code drop('IT was too slow so business department X decided to hire someone themselves'), fear for your sanity.

ternaus 4y ago

I have heard a story about developer who deleted all the code in the company that was not covered with tests. Everything stopped working. His changes were reverted back. But within a month all code base was covered with tests.

vultour 4y ago
I don't see how one leads to the other. The only outcome of this should be immediate termination.
- weard_beard 4y ago
  Everything did, indeed, terminate.