Re:Notes on Modifying Unowned Code (2021)
by hyperman1 on Wednesday September 28, 2022 @11:03AM
(#33008815)
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.
Re:Notes on Modifying Unowned Code (2021)
by woleium on Tuesday September 27, 2022 @05:38PM
(#33001452)
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.
Re:Notes on Modifying Unowned Code (2021)
by charles_f on Wednesday September 28, 2022 @11:01AM
(#33008786)
> 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.
* 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.
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.
Everything stopped working. His changes were reverted back.
But within a month all code base was covered with tests.