5 ms·

Maintaining that kind of code is often less about dealing with lingering bugs, than it is about making sure that it's kept in sync with changes to the rest of t

by rosser 7y ago

Maintaining that kind of code is often less about dealing with lingering bugs, than it is about making sure that it's kept in sync with changes to the rest of the kernel that might be relevant. If some kernel structure that the FDD driver uses changes, it needs to know that. EDIT: Phrasing

ergothus 7y ago
> about making sure that it's kept in sync with changes to the rest At one of my workplaces we had an application that was without a formal supporter and everyone hated to touch it. After I was assigned to dive in to fix a bug, I did a study of how it got that way. I was very surprised by the results I found. Basically, two things went wrong: * Firstly, due to some mismanagement, the local team moved away, leaving it unsupported. * Secondly, outside code underwent some paradigm shifts, meaning that anyone who knew outside code found this code to be foreign. Often, people assigned to fix bugs/add features in this code would try to apply the outside paradigms without understanding or adapting the local conventions, creating ugly code interfaces. Here was the part that amazed me: The time between this code being not-perfect-but-perfectly-normal and becoming ugh-I-hope-I-don't-have-to-touch-that was _6 months_(!) We've always known that technical debt becomes a problem, but I had no idea it would compound so quickly. Granted, this was at a "post-startup" company going through rapid change as the scope of work kept increasing, but that's still a startlingly fast decay rate for code that was decently written and tested. Definitely proved to me the value of an active maintainer.
- rosser 7y ago
  Yeah, that kind of "process" probably invites code rot. It's subtle, insidious, and yes, sometimes, shockingly quick to set in.
- rodgerd 7y ago
  As a witter person that I put it, "code ages like milk, not like wine".
- tylerrobinson 7y ago
  It's remarkable how closely this fits with a system at my company. Without close attention, things can spiral out of control faster than you can imagine.
dfcmt 7y ago
That's what happens when you choose not to have a stable API for drivers. Maybe Linux developers should reconsider that ;-)

by rosser 7y ago

ergothus 7y ago

> about making sure that it's kept in sync with changes to the rest At one of my workplaces we had an application that was without a formal supporter and everyone hated to touch it. After I was assigned to dive in to fix a bug, I did a study of how it got that way. I was very surprised by the results I found. Basically, two things went wrong: * Firstly, due to some mismanagement, the local team moved away, leaving it unsupported. * Secondly, outside code underwent some paradigm shifts, meaning that anyone who knew outside code found this code to be foreign. Often, people assigned to fix bugs/add features in this code would try to apply the outside paradigms without understanding or adapting the local conventions, creating ugly code interfaces. Here was the part that amazed me: The time between this code being not-perfect-but-perfectly-normal and becoming ugh-I-hope-I-don't-have-to-touch-that was _6 months_(!) We've always known that technical debt becomes a problem, but I had no idea it would compound so quickly. Granted, this was at a "post-startup" company going through rapid change as the scope of work kept increasing, but that's still a startlingly fast decay rate for code that was decently written and tested. Definitely proved to me the value of an active maintainer.

rosser 7y ago
Yeah, that kind of "process" probably invites code rot. It's subtle, insidious, and yes, sometimes, shockingly quick to set in.
rodgerd 7y ago
As a witter person that I put it, "code ages like milk, not like wine".
tylerrobinson 7y ago
It's remarkable how closely this fits with a system at my company. Without close attention, things can spiral out of control faster than you can imagine.

dfcmt 7y ago

That's what happens when you choose not to have a stable API for drivers. Maybe Linux developers should reconsider that ;-)