5 ms·

"Temp code" is the biggest lie anyone will ever tell you as a programmer. Everyone will have perfectly good intentions, from PMs to directors to ICs, but "this

"Temp code" is the biggest lie anyone will ever tell you as a programmer. Everyone will have perfectly good intentions, from PMs to directors to ICs, but "this is only temporary" almost never is.

dgb23 6y ago
I agree in some sense. But I have found that every code base needs some kind of way to write "temporary" code AKA code that needs to be refactored at least. If you don't define a place (and time) for this then it will happen anyway. Just all over your code base: patches, fixes, workarounds, todos. The clearer it is to distinguish temporary code the better: "Start just writing what works here and then gradually move pieces of it over there, while testing and refactoring it." When your code and communication is setup like this, then you will naturally incorporate this process because it is both pragmatic and very visible to everyone.
lmkg 6y ago
It's not specific to programming, though. For example, even after completing new buildings, I've never seen a school reduce the number of "temporary" portable classrooms they use to teach classes.
WrtCdEvrydy 6y ago
Right up there with "We'll come back and fix it", "We'll refactor it later" and "We can add the tests later" It won't happen, and it has never happened unless those sections end up failing catastrophically. We don't have enough money to do it right once, but we have enough money to it wrong twice - Me, 3 years ago.
- WalterBright 6y ago
  I'm still regularly refactoring code I initially wrote 35 years ago. https://github.com/dlang/dmd/pull/11301 https://github.com/dlang/dmd/pull/11301
  - tluyben2 6y ago
    I would be too in your case, but all of my work is for clients, not for the 'greater good'... Keep up the good work!
tluyben2 6y ago
No-one ever told me but myself. That's why I would tell my younger self that if I could with the hope it would stick long-term. I mean, in any other field (which we shouldn't compare to, but what else can we do that makes it sound as insane is it really is?) do you get something like; 'let's make an emergency bridge out of two planks over this bit of highway because the real bridge has been flooded' and then 25 years later people are still driving over those planks causing traffic jams and accidents (we have to ducktape those planks all the time)? If I write something that is just to keep something running 'for a couple of days' and then ends up being part of a backbone for a company (because it ain't broken, so why replace it?) is something I could not expect but there are at least 50+ 'blobs of software' out there by me where exactly that happened over the decades.
deleted 6y ago
[deleted]
bcrosby95 6y ago
"Temp code" is fine. In fact, I'll go a step further: it doesn't matter how shitty a piece of code is if you never have to touch it again. The way you deal with "temp code" is to slightly improve the aspect you are changing, each time you change it. Maybe you did something weirdly hacky with magic numbers everywhere - when you need to add another magic number you refactor that aspect to no longer use them. Or maybe if they're starting to look more like types you do a refactor to enums or classes. Then the places that can be shitty remain shitty. The places that can't are fixed up over time.

"Temp code" is the biggest lie anyone will ever tell you as a programmer. Everyone will have perfectly good intentions, from PMs to directors to ICs, but "this is only temporary" almost never is.

dgb23 6y ago

I agree in some sense. But I have found that every code base needs some kind of way to write "temporary" code AKA code that needs to be refactored at least. If you don't define a place (and time) for this then it will happen anyway. Just all over your code base: patches, fixes, workarounds, todos. The clearer it is to distinguish temporary code the better: "Start just writing what works here and then gradually move pieces of it over there, while testing and refactoring it." When your code and communication is setup like this, then you will naturally incorporate this process because it is both pragmatic and very visible to everyone.

lmkg 6y ago

It's not specific to programming, though. For example, even after completing new buildings, I've never seen a school reduce the number of "temporary" portable classrooms they use to teach classes.

WrtCdEvrydy 6y ago

Right up there with "We'll come back and fix it", "We'll refactor it later" and "We can add the tests later" It won't happen, and it has never happened unless those sections end up failing catastrophically. We don't have enough money to do it right once, but we have enough money to it wrong twice - Me, 3 years ago.

WalterBright 6y ago
I'm still regularly refactoring code I initially wrote 35 years ago. https://github.com/dlang/dmd/pull/11301 https://github.com/dlang/dmd/pull/11301
- tluyben2 6y ago
  I would be too in your case, but all of my work is for clients, not for the 'greater good'... Keep up the good work!

tluyben2 6y ago

No-one ever told me but myself. That's why I would tell my younger self that if I could with the hope it would stick long-term. I mean, in any other field (which we shouldn't compare to, but what else can we do that makes it sound as insane is it really is?) do you get something like; 'let's make an emergency bridge out of two planks over this bit of highway because the real bridge has been flooded' and then 25 years later people are still driving over those planks causing traffic jams and accidents (we have to ducktape those planks all the time)? If I write something that is just to keep something running 'for a couple of days' and then ends up being part of a backbone for a company (because it ain't broken, so why replace it?) is something I could not expect but there are at least 50+ 'blobs of software' out there by me where exactly that happened over the decades.

deleted 6y ago

[deleted]

bcrosby95 6y ago

"Temp code" is fine. In fact, I'll go a step further: it doesn't matter how shitty a piece of code is if you never have to touch it again. The way you deal with "temp code" is to slightly improve the aspect you are changing, each time you change it. Maybe you did something weirdly hacky with magic numbers everywhere - when you need to add another magic number you refactor that aspect to no longer use them. Or maybe if they're starting to look more like types you do a refactor to enums or classes. Then the places that can be shitty remain shitty. The places that can't are fixed up over time.