5 ms·

"don't reinvent the wheel" is specifically for projects which other people will be forced to maintain. You can reinvent the wheel as many times you want. If yo

"don't reinvent the wheel" is specifically for projects which other people will be forced to maintain. You can reinvent the wheel as many times you want. If you however do that at work, your colleagues and your replacement after you left the job likely won't think too kindly of you.

jraph 6y ago
true, but it is a balance. If you import packages for things that can be done in one small function, you force them a lot of dependencies, which can be worse.
tutfbhuf 6y ago
I think that developers, albeit knowing about "don't reinvent the wheel", will do it nonetheless. I think psychological factors play a role here, like the "IKEA effect": > The IKEA effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. The name refers to Swedish manufacturer and furniture retailer IKEA, which sells many items of furniture that require assembly. A 2011 study found that subjects were willing to pay 63% more for furniture they had assembled themselves, than for equivalent pre-assembled items. https://en.wikipedia.org/wiki/IKEA_effect https://en.wikipedia.org/wiki/IKEA_effect I think this effect also applies to developers. They tend to value self-written applications subconsciously higher than "pre-assembled" applications.
- vbezhenar 6y ago
  I value self-written applications consciously. Because I know everything about them, I can quickly change everything, adapt it as I need, fix any issues. That's not true for other applications and might be impossible for proprietary ones. I don't think that this is the same about Ikea, though. If I bought Ikea table, I can't really adapt it, unless I'm advanced woodsman with proper tools. If I'm just ordinary guy with screwdriver, I can just follow the script to build that table. I think that Ikea analogue is someone building his vim environment from other's plugins following guides. He does not know C, so he can't hack vim, he does not know vim configuration language, so he can't hack plugins.
  - tutfbhuf 6y ago
    As a developer you will always use tools and rely on applications others have written. If you write your program in C, then you use a C compiler like gcc and most developers have not read the whole source code of gcc. Same is true for the C library you use, including standard library, you rely on others developers code you have never seen. Therefore, I think the IKEA effect holds true in software development, because you rely on "pre-assembled" items, but I agree that you have much larger degree or freedom on how you build your application in e.g. C compared to a IKEA build. Maybe, this higher degree of freedom even strengthens the effect.
- slx26 6y ago
  While I don't disagree, there might be many other issues: - Frameworks and tools are almost always ill-fitting. You have many features you don't need, you lack many features you need. You have dependencies you don't want, code that you don't know, models that might not match your own (and might not be explained well enough, or might not even be consistent with themselves anyway). - Frameworks and tools are often leaky. They don't solve problems perfectly anyway. They substitute the problem of having to develop a custom solution to the problem with having to figure out how to use the tool effectively, plus any problems derived of the shortcomings of the tool itself, which are often harder to solve on a tool you didn't develop yourself. The better you want to do something, the more disappointed you become with leaky solutions. And other people leaks are far more uncomfortable than your own leaks. - Some people just want to have control and know what they are doing, even if they need to put much more work on it. Not productive, but more consistent. - Writing your own tools deepens your understanding of the landscape. This is particularly significant in a world where we have hundreds of frameworks and tools, but very few coherent explanations of the context they work on and the problems they really try to solve. We have reached the point where if someone wants to make a non-trivial website, we tell them to learn React instead of sending them to learn how the internet and websites work so they can choose a tool for their needs afterwards. And this piles up and giving coherent explanations of any landscape becomes harder because no landscape is coherent anymore. - Related to the previous, there's a certain trend that emerges where the more dependent we become on frameworks and tools, the more the problems in a given scenario are ignored or solved by adding more abstration layers and fancier features on tools, instead of working on the root underlying issues, and the problems become fuzzier. Working on the actual problems by yourself helps you see how much cruft and dirt there is behind even well established technologies... and some of us are masochists and want to know about all that sh*t, because if it remains hidden there's little chance to fix it.
  - tutfbhuf 6y ago
    > Frameworks and tools are often leaky. They don't solve problems perfectly anyway. How about compilers?
    - slx26 6y ago
xorcist 6y ago
That analogy only stretches so far. I'd much rather inherit a project that contains 'sprintf("%010d", i)', or equivalent, than one with yet another dependency. Especially when repeated a thousand times over the course on an entire project. Every dependency is one that I must understand all the possible return types, failure modes, and upgrade paths. Every function is one that I must read. The needle must be quite clearly on the benefits side in order to be worth it.
johnisgood 6y ago
Well, in that case you should document your code extensively. Document the code in the source code (but please do not have your files in a 90% comment 10% code ratio), and document it elsewhere, too, so your code will not be filled with documentation. I truly hate going through code that has more documentation than code. I often just use a tool that moves all the comments to a separate file.
magnostherobot 6y ago
Maybe it shouldn't be "don't reinvent the wheel", but rather "reinvent the wheel well"
MaxBarraclough 6y ago
I think this depends on the specifics. It's not always just about maintainability. You shouldn't reinvent Django if other members of your team already know Django, as you're imposing a learning cost in doing so. You rather obviously shouldn't reinvent the Linux kernel, as doing so is an enormous undertaking. It's probably a huge waste of resources, your solution will probably be far inferior, and you're likely to fail anyway. You shouldn't reimplement TLS, as you will almost certainly do so incorrectly, and it would take a great deal of effort. It's a waste of resources and will worsen your cybersecurity risk profile.
- doublerabbit 6y ago
  I disagree. It's not recommended that you should reimplement TLS. "Shouldn't" is the wrong word in use. Why should you not? You only learn by developing. Precautions follow with such, as likes not running in production. But how else do you learn if you do not? If your interested in learning about secure sockets and the rest, you should reimplement TLS. Because that will teach you the inner workings of TLS. The vibe "you shouldn't" crushes the development side of things.
  - MaxBarraclough 6y ago
    Sure, reimplementing TLS is a great way to learn the protocol. We were discussing reimplementing things with an eye to then using that implementation for serious work, but yes, reimplementing as a learning exercise is an exception, provided you never use your toy implementation in production. > "Shouldn't" is the wrong word to use. Why should you not? I'll assume that here you're not referring to reimplementing purely as a learning exercise. I already said why: you will almost certainly do so incorrectly, and this will worsen your cybersecurity risk profile. For serious work, you should use a mature battle-tested implementation like everyone else. The slightest error in a cryptography codebase can lead to severe security vulnerabilities. This is well understood and much has been written on the topic of don't roll your own crypto, e.g. https://security.stackexchange.com/a/18198/ https://security.stackexchange.com/a/18198/ > The vibe "you shouldn't" crushes the development side of things. No, it's solid cybersecurity advice. It's irresponsible to make use of either an amateur cryptographic scheme, or an amateur implementation of a cryptographic scheme, in a serious codebase. Reimplementing TLS purely as a learning exercise is of course still to be encouraged. More generally, there is no culture of you shouldn't posing a problem in the software development world. Nuclear engineers and bridge engineers are taught you shouldn't... but software developers are taught just go for it.
lucideer 6y ago
If your colleagues and replacements can't maintain the code you wrote, the fact that you didn't use 3rd-party code instead is not the problem.
- lucideer 6y ago
  Addendum: just to clarify, installing 3rd-party library dependencies is a good idea. There are many good reasons to do so. This just isn't one of them. I've encountered ~100% custom codebases that are unmaintainable, and I've encountered ~100% custom codebases that are extremely maintainable, even for a new person joining a team. And we're not talking about leftPad-esque libs; entire frameworks made in-house. It's rare, and there are reasons to avoid it (locking yourself into your own tech, not benefiting from community innovation, not being "on trend" with common dev conventions). But ease of maintenance is not one of those reasons. If it's hard to maintain, that's on you.

jraph 6y ago

true, but it is a balance. If you import packages for things that can be done in one small function, you force them a lot of dependencies, which can be worse.

tutfbhuf 6y ago

I think that developers, albeit knowing about "don't reinvent the wheel", will do it nonetheless. I think psychological factors play a role here, like the "IKEA effect": > The IKEA effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. The name refers to Swedish manufacturer and furniture retailer IKEA, which sells many items of furniture that require assembly. A 2011 study found that subjects were willing to pay 63% more for furniture they had assembled themselves, than for equivalent pre-assembled items. https://en.wikipedia.org/wiki/IKEA_effect https://en.wikipedia.org/wiki/IKEA_effect I think this effect also applies to developers. They tend to value self-written applications subconsciously higher than "pre-assembled" applications.

vbezhenar 6y ago
I value self-written applications consciously. Because I know everything about them, I can quickly change everything, adapt it as I need, fix any issues. That's not true for other applications and might be impossible for proprietary ones. I don't think that this is the same about Ikea, though. If I bought Ikea table, I can't really adapt it, unless I'm advanced woodsman with proper tools. If I'm just ordinary guy with screwdriver, I can just follow the script to build that table. I think that Ikea analogue is someone building his vim environment from other's plugins following guides. He does not know C, so he can't hack vim, he does not know vim configuration language, so he can't hack plugins.
- tutfbhuf 6y ago
  As a developer you will always use tools and rely on applications others have written. If you write your program in C, then you use a C compiler like gcc and most developers have not read the whole source code of gcc. Same is true for the C library you use, including standard library, you rely on others developers code you have never seen. Therefore, I think the IKEA effect holds true in software development, because you rely on "pre-assembled" items, but I agree that you have much larger degree or freedom on how you build your application in e.g. C compared to a IKEA build. Maybe, this higher degree of freedom even strengthens the effect.
slx26 6y ago
While I don't disagree, there might be many other issues: - Frameworks and tools are almost always ill-fitting. You have many features you don't need, you lack many features you need. You have dependencies you don't want, code that you don't know, models that might not match your own (and might not be explained well enough, or might not even be consistent with themselves anyway). - Frameworks and tools are often leaky. They don't solve problems perfectly anyway. They substitute the problem of having to develop a custom solution to the problem with having to figure out how to use the tool effectively, plus any problems derived of the shortcomings of the tool itself, which are often harder to solve on a tool you didn't develop yourself. The better you want to do something, the more disappointed you become with leaky solutions. And other people leaks are far more uncomfortable than your own leaks. - Some people just want to have control and know what they are doing, even if they need to put much more work on it. Not productive, but more consistent. - Writing your own tools deepens your understanding of the landscape. This is particularly significant in a world where we have hundreds of frameworks and tools, but very few coherent explanations of the context they work on and the problems they really try to solve. We have reached the point where if someone wants to make a non-trivial website, we tell them to learn React instead of sending them to learn how the internet and websites work so they can choose a tool for their needs afterwards. And this piles up and giving coherent explanations of any landscape becomes harder because no landscape is coherent anymore. - Related to the previous, there's a certain trend that emerges where the more dependent we become on frameworks and tools, the more the problems in a given scenario are ignored or solved by adding more abstration layers and fancier features on tools, instead of working on the root underlying issues, and the problems become fuzzier. Working on the actual problems by yourself helps you see how much cruft and dirt there is behind even well established technologies... and some of us are masochists and want to know about all that sh*t, because if it remains hidden there's little chance to fix it.
- tutfbhuf 6y ago
  > Frameworks and tools are often leaky. They don't solve problems perfectly anyway. How about compilers?
  - slx26 6y ago

xorcist 6y ago

That analogy only stretches so far. I'd much rather inherit a project that contains 'sprintf("%010d", i)', or equivalent, than one with yet another dependency. Especially when repeated a thousand times over the course on an entire project. Every dependency is one that I must understand all the possible return types, failure modes, and upgrade paths. Every function is one that I must read. The needle must be quite clearly on the benefits side in order to be worth it.

johnisgood 6y ago

Well, in that case you should document your code extensively. Document the code in the source code (but please do not have your files in a 90% comment 10% code ratio), and document it elsewhere, too, so your code will not be filled with documentation. I truly hate going through code that has more documentation than code. I often just use a tool that moves all the comments to a separate file.

magnostherobot 6y ago

Maybe it shouldn't be "don't reinvent the wheel", but rather "reinvent the wheel well"

MaxBarraclough 6y ago

I think this depends on the specifics. It's not always just about maintainability. You shouldn't reinvent Django if other members of your team already know Django, as you're imposing a learning cost in doing so. You rather obviously shouldn't reinvent the Linux kernel, as doing so is an enormous undertaking. It's probably a huge waste of resources, your solution will probably be far inferior, and you're likely to fail anyway. You shouldn't reimplement TLS, as you will almost certainly do so incorrectly, and it would take a great deal of effort. It's a waste of resources and will worsen your cybersecurity risk profile.

doublerabbit 6y ago
I disagree. It's not recommended that you should reimplement TLS. "Shouldn't" is the wrong word in use. Why should you not? You only learn by developing. Precautions follow with such, as likes not running in production. But how else do you learn if you do not? If your interested in learning about secure sockets and the rest, you should reimplement TLS. Because that will teach you the inner workings of TLS. The vibe "you shouldn't" crushes the development side of things.
- MaxBarraclough 6y ago
  Sure, reimplementing TLS is a great way to learn the protocol. We were discussing reimplementing things with an eye to then using that implementation for serious work, but yes, reimplementing as a learning exercise is an exception, provided you never use your toy implementation in production. > "Shouldn't" is the wrong word to use. Why should you not? I'll assume that here you're not referring to reimplementing purely as a learning exercise. I already said why: you will almost certainly do so incorrectly, and this will worsen your cybersecurity risk profile. For serious work, you should use a mature battle-tested implementation like everyone else. The slightest error in a cryptography codebase can lead to severe security vulnerabilities. This is well understood and much has been written on the topic of don't roll your own crypto, e.g. https://security.stackexchange.com/a/18198/ https://security.stackexchange.com/a/18198/ > The vibe "you shouldn't" crushes the development side of things. No, it's solid cybersecurity advice. It's irresponsible to make use of either an amateur cryptographic scheme, or an amateur implementation of a cryptographic scheme, in a serious codebase. Reimplementing TLS purely as a learning exercise is of course still to be encouraged. More generally, there is no culture of you shouldn't posing a problem in the software development world. Nuclear engineers and bridge engineers are taught you shouldn't... but software developers are taught just go for it.

lucideer 6y ago

If your colleagues and replacements can't maintain the code you wrote, the fact that you didn't use 3rd-party code instead is not the problem.

lucideer 6y ago
Addendum: just to clarify, installing 3rd-party library dependencies is a good idea. There are many good reasons to do so. This just isn't one of them. I've encountered ~100% custom codebases that are unmaintainable, and I've encountered ~100% custom codebases that are extremely maintainable, even for a new person joining a team. And we're not talking about leftPad-esque libs; entire frameworks made in-house. It's rare, and there are reasons to avoid it (locking yourself into your own tech, not benefiting from community innovation, not being "on trend" with common dev conventions). But ease of maintenance is not one of those reasons. If it's hard to maintain, that's on you.