8 ms·

The Code It Yourself Manifesto (2016)

106 points by rutenspitz 6y ago

teddyh 6y ago
Related: In Defense of Not-Invented-Here Syndrome (2001): https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
niek_pas 6y ago
Doesn’t this quickly become untenable? Sure, you might be able to code some of your own tools, but what about the OS those tools run on? Hardware? Drivers?
- TrueDuality 6y ago
  This is kind of covered in that manifesto itself in that you only go down the road of making something yourself when the tools you use no longer match your use case. A lot of tools will be fine or meet your goals, such as your OS. If your OS doesn't match your goals then you're left with the three options detailed. In the case of an OS, the "big" OS's probably meet most people's general computing needs. It's not uncommon to write a custom "OS" for embedded devices. Some people do feel like making their own OS and there are plenty of examples out there of them and that's perfectly fine. Anything like this is also not written as law. Your text editor annoys you under these certain conditions? You don't have to rewrite it, fix it, or switch to another editor. If you're compelled to write a replacement, it shouldn't be stigmatized which rewriting existing software frequently is.
- einpoklum 6y ago
  It _immediately_ becomes untenable, actually. It'll like telling people to "manufacture it yourself". That might be possible for a perfectly fit person living a Robinson Crusoe life in some remote region; otherwise it's just divorced from reality. We are a social animal - "zoon politicon" in Plato's original Greek - and our activities are social. For better and for worse, we can't declare that not to be the case or claim that we want to just be "left alone".
- nullsense 6y ago
  TempleOS
cjfd 6y ago
It is generally good to depend on well-tested, large and reliable libraries. I have done the code-it-yourself thing to smaller libraries, though. The quality of the maintenance work done on smaller libraries is by no means guaranteed. They can acquire bugs at any point in time and when they do it may be best to just replace them by home written replacements.
- orclev 6y ago
  A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you. In a similar vein, a well known standard format (or encoding) will always be a better choice than some ad-hoc format you create yourself because not only will that standard have encountered and dealt with problems you haven't even considered, but there are also likely to be a plethora of libraries, frameworks, and tools that support that format, where as if you create something yourself you end up needing to create anything you need. Your time is generally better spent working on solving your core problem rather than the dozens of ancillary problems that end up needing to be solved along the way (particularly where a whole bunch of other people have spent a whole bunch of time already solving those problems).
  - Ma8ee 6y ago
    > A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you. Yes, but a large complicated well maintained and widely used library is not necessarily preferable to a small not so complicated library that does exactly what you need and nothing else. And that goes for formats too. Recently I was involved in a project where order numbers had to be sent from one system to another. Some colleagues insisted that we baked them into a large xml document and then used libraries to both create the documents as well as parse them. In this case the economic thing to do was to write them each separated by EOL. Even the code we would have written ourselves would have been larger if we’d used the XML solution, not to talk about everything needed to include in builds and deploys.
    - 6y ago
einpoklum 6y ago
While I certainly would encourage and do encourage people to code (it) themselves, the claim that using that not doing so > mean[s] endless seeking, evaluating and further deviation from our goals. is simply not true. Only if software were written to serve ultra-particular and individual goals would that be the case. Software is written to serve needs - of fewer or of many. And while it may serve a more constrained set of needs more optimally, it typically serves wide enough needs well enough, that the vast majority of people have most of their software needs met by software written by others (albeit with room for improvement). Also, almost no person, even a proficient coder, has enough time and attention span to code most of the software they use. On the contrary, we absolutely and necessary _won't and can't_ code "it" ourselves, where "it" is the main bulk of software we use over the course of our lives. ---- Instead of this manifesto, I would suggest a "Write good, robust, widely-usable libraries" manifesto - because that's how other people will be realistically able to code "it" themselves when and if they need to.
- forgotmypw17 6y ago
  I don't know, it's certainly been the pattern I've experienced with Slashdot, reddit, Facebook, Twitter, Instagram, Windows, Debian, Ubuntu, Mac, Firefox, Chrome, Hotmail, Yahoo Mail, Gmail, Android, iOS, and so many other services and software that I'd be sitting here all day counting them all. First, I find something which suits me. Then, it starts growing from under me, typically in the direction of bloat and feature removal. Then, the usefulness to abuse ratio drops gradually. Then, I'm faced with having to migrate or simply abandon yet another platform. It's a serious issue, but I believe we can overcome it with just this sort of approach combining FLOSS and dogfooding.
bArray 6y ago
One thing I would add is that it's much easier to appreciate existing solutions when you try to build your own. Often these "I could code something better in a day" thoughts turns into thinking "it's a tougher problem than I though". Other times, though, either I learn something, or end up making something that is much better for me to use. I would suggest at some time every programmer try build their own limited scope library if they find existing solutions do not meet their requirements.
okareaman 6y ago
I should write a manifesto about cooking for oneself instead of eating in restaurants, but then halfway through I'd think "why not both?
kstenerud 6y ago
While I appreciate the sentiment behind this, with experience comes a sixth sense of what should be rebuilt, and what is better reused/modified. Experience also brings with it an ability to scan through foreign code and get a "feel" for how usable it is. For example, I've chosen to replace one of the foundational data communication building blocks [1] because, after extensive research, the existing systems can't be modified to handle all of the general use cases I want handled. And it won't stop there, because I also have a number of additional requirements that HTTP won't handle (so there's also a new protocol in the works that will be based off this technology). If I could have simply modified an existing system to do what I want, I certainly wouldn't have spent the last two years on this! I've got plenty of other things demanding my attention... [1] https://concise-encoding.org https://concise-encoding.org
mjw1007 6y ago
Nowadays an approach that I find often worth trying is: - download a project in a suitable language that claims to do what you need - read its list of direct dependencies - implement your own thing using those same libraries - write your own replacement for any of those libraries that seem more trouble than they're worth. Indications for when this is likely to go well: - the top-level piece of software has grown its own configuration language - the the top-level piece of software has dozens of options for tuning its behaviour - the maintainers of the top-level piece of software have spun parts of it out as libraries, and they're being used by other people.
deleted 6y ago
[deleted]
SarikayaKomzin 6y ago
I like the idea of a “yeoman” programmer/engineer movement. It’s like homesteading except for consumer appliances/software — sustenance coding. I was happy to see a step-by-step guide to building a doorbell camera on the front page yesterday.
malwrar 6y ago
I believe the first step when creating something new aught to be answering honestly for yourself why existing solutions won’t work for you. Your time is valuable and much better spent building something no one else has yet. I was once heavily afflicted by NIH, but with experience I realized how much time I was wasting stubbornly trying to reinvent the wheel. That’s actually a great analogy if you think about it—-the original wheels were fashioned out of wood and are quite simple in concept, but creating modern wheels require s tons of specialized tools and knowledge to build. It doesn’t make sense to attempt this if I can just buy a premade one that suits my needs. That premade wheel also has the benefit of huge amounts of iteration in response to problems encountered over time, and I would probably need to replicate at least some of that in order to build something competitive with the existing solution. In the realm of code, using other people’s solutions when available lets me focus on the original problem I want to solve. It also allows me to minimize the amount of code I need to actually maintain myself, since typically there’s a group of people that are collectively much more knowledgeable than me doing that for free. If I ever do have a reason to know how the library works (patches, bug fixes, behavioral questions, curiosity), I’ve found it much quicker to figure out how the code works rather than write my own.
- asddubs 6y ago
  I would say "code it yourself, if it doesn't significantly slow you down". There's definitely something to be said for minimizing your dependencies, but if you're spending weeks implementing things completely tangential to what you're trying to do, you made a wrong turn somewhere. It's all about picking your battles, and I think you can go too far in both directions.
  - nullsense 6y ago
    I'm personally starting to take the view of "sharpen your tools". That is, I'm fine with taking dependencies where appropriate, but I'm starting to contribute fixes and improvements to them as a way to derisk them. I think that benefits everyone.
- bullen 6y ago
  I think you mean re-implement the wheel, people often misuse the term re-invent the wheel. You actually need to change things for it to be called an invention: http://move.rupy.se/file/wheel.jpg http://move.rupy.se/file/wheel.jpg That said I always write everything from scratch, to me it's the meaning of life; If you are only using things you don't understand, you cannot (re-)invent anything. Today we also do not own anything, which makes the problem even worse. Rules for a good life: 1) own 2) understand 3) change!
forgotmypw17 6y ago
I agree completely. After dealing with the same sort of rot pattern in both software and services for years, I've set out to replace as much as I can with my own tooling. Mostly this has meant developing a hybrid blogging, forum, note-taking and writing, DAG database, information archiving and retrieval system and dogfooding it as much as possible.
keb_ 6y ago
I see the philosophy of "don't reinvent the wheel" taken to extremes in the React world, and before that, in the jQuery world. There is simply a plugin/component library for anything and everything you need to do, so relatively simple applications have monstrous dependency trees because it's easier to `npm install` the whole kitchen sink and use the little bits you need, than taking some time to understand & implement a smaller, focused alternative that could live in a `util.js` file in your project. At least thanks to tree-shaking and bundler innovations, the end-users don't suffer from bloated bundle downloads, but your node_modules folder is still 600MB large.
bitwize 6y ago
In business this is known as the build/buy dichotomy. Best practice is to focus on your core competencies. Meaning buy unless the available solutions do not fit your needs or are cost-prohibitive. As always, it all boils down to cost. "Code it yourself" may make your programmers happy, and give them interesting work to do, but if it costs the business a big chunk of money they could have saved or put to more profitable efforts, it's a very bad idea.
mro_name 6y ago
awesome. There's indeed one sole reliable supplier that really cares. Sadly sometimes not as competent or available as you'd like.
ur-whale 6y ago
However attractive the proposition may be, there is one, tiny fly in the ointment: time Of which there isn't much to go round, and very much of which would go down the drain if one were to follow that philosophy to get things done. Oh, and ... there's also all those pesky people who don't really know how to code.
kissgyorgy 6y ago
There is a huge missing point which overweights everything else; it's really expensive (in time or maybe in money) to develop your own software even if you are a good developer.
jaaron 6y ago
First: If the code is for you, and for you exclusively, go ahead. If you're writing code as part of a team for a customer, then it isn't for you and it's whole purpose is to solve the problem at hand. Secondly: The primary issue I have with a NIH code-it-yourself approach is that it doesn't scale over time. Professionally, over two decades, I have seen several teams go through a technical evaluation and decide, in the end, that no open or closed source solution exactly fit their needs. So they coded it themselves. Fast forward three to five years and everyone regretted the NIH approach. Those open or closed source solutions had matured and easily surpassed the home grown feature set, which still required a team of engineers to invest in. There are exceptions, of course. Sometimes you have to build it yourself. But more often than not, it's much, much more effective to let go of your ego and collaborate with others, particularly on open source solutions in which you always have the option to fork the codebase and bring it, effectively, in house. Generally, I find those that strongly advocate for NIH overly discount the long term costs of maintaining software.
- twblalock 6y ago
  > Fast forward three to five years and everyone regretted the NIH approach. Those open or closed source solutions had matured and easily surpassed the home grown feature set, which still required a team of engineers to invest in. This is the root of the problem: a small team generally can't keep up with an open source project over time. The NIH approach works well at larger companies who can dedicate a lot of engineers to working on in-house infrastructure projects full time. At smaller companies it is a distraction from building the core product.

106 points by rutenspitz 6y ago

Related: In Defense of Not-Invented-Here Syndrome (2001): https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

niek_pas 6y ago

Doesn’t this quickly become untenable? Sure, you might be able to code some of your own tools, but what about the OS those tools run on? Hardware? Drivers?

TrueDuality 6y ago
This is kind of covered in that manifesto itself in that you only go down the road of making something yourself when the tools you use no longer match your use case. A lot of tools will be fine or meet your goals, such as your OS. If your OS doesn't match your goals then you're left with the three options detailed. In the case of an OS, the "big" OS's probably meet most people's general computing needs. It's not uncommon to write a custom "OS" for embedded devices. Some people do feel like making their own OS and there are plenty of examples out there of them and that's perfectly fine. Anything like this is also not written as law. Your text editor annoys you under these certain conditions? You don't have to rewrite it, fix it, or switch to another editor. If you're compelled to write a replacement, it shouldn't be stigmatized which rewriting existing software frequently is.
einpoklum 6y ago
It _immediately_ becomes untenable, actually. It'll like telling people to "manufacture it yourself". That might be possible for a perfectly fit person living a Robinson Crusoe life in some remote region; otherwise it's just divorced from reality. We are a social animal - "zoon politicon" in Plato's original Greek - and our activities are social. For better and for worse, we can't declare that not to be the case or claim that we want to just be "left alone".
nullsense 6y ago
TempleOS

cjfd 6y ago

It is generally good to depend on well-tested, large and reliable libraries. I have done the code-it-yourself thing to smaller libraries, though. The quality of the maintenance work done on smaller libraries is by no means guaranteed. They can acquire bugs at any point in time and when they do it may be best to just replace them by home written replacements.

orclev 6y ago
A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you. In a similar vein, a well known standard format (or encoding) will always be a better choice than some ad-hoc format you create yourself because not only will that standard have encountered and dealt with problems you haven't even considered, but there are also likely to be a plethora of libraries, frameworks, and tools that support that format, where as if you create something yourself you end up needing to create anything you need. Your time is generally better spent working on solving your core problem rather than the dozens of ancillary problems that end up needing to be solved along the way (particularly where a whole bunch of other people have spent a whole bunch of time already solving those problems).
- Ma8ee 6y ago
  > A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you. Yes, but a large complicated well maintained and widely used library is not necessarily preferable to a small not so complicated library that does exactly what you need and nothing else. And that goes for formats too. Recently I was involved in a project where order numbers had to be sent from one system to another. Some colleagues insisted that we baked them into a large xml document and then used libraries to both create the documents as well as parse them. In this case the economic thing to do was to write them each separated by EOL. Even the code we would have written ourselves would have been larger if we’d used the XML solution, not to talk about everything needed to include in builds and deploys.
  - 6y ago

einpoklum 6y ago

While I certainly would encourage and do encourage people to code (it) themselves, the claim that using that not doing so > mean[s] endless seeking, evaluating and further deviation from our goals. is simply not true. Only if software were written to serve ultra-particular and individual goals would that be the case. Software is written to serve needs - of fewer or of many. And while it may serve a more constrained set of needs more optimally, it typically serves wide enough needs well enough, that the vast majority of people have most of their software needs met by software written by others (albeit with room for improvement). Also, almost no person, even a proficient coder, has enough time and attention span to code most of the software they use. On the contrary, we absolutely and necessary _won't and can't_ code "it" ourselves, where "it" is the main bulk of software we use over the course of our lives. ---- Instead of this manifesto, I would suggest a "Write good, robust, widely-usable libraries" manifesto - because that's how other people will be realistically able to code "it" themselves when and if they need to.

forgotmypw17 6y ago
I don't know, it's certainly been the pattern I've experienced with Slashdot, reddit, Facebook, Twitter, Instagram, Windows, Debian, Ubuntu, Mac, Firefox, Chrome, Hotmail, Yahoo Mail, Gmail, Android, iOS, and so many other services and software that I'd be sitting here all day counting them all. First, I find something which suits me. Then, it starts growing from under me, typically in the direction of bloat and feature removal. Then, the usefulness to abuse ratio drops gradually. Then, I'm faced with having to migrate or simply abandon yet another platform. It's a serious issue, but I believe we can overcome it with just this sort of approach combining FLOSS and dogfooding.

bArray 6y ago

One thing I would add is that it's much easier to appreciate existing solutions when you try to build your own. Often these "I could code something better in a day" thoughts turns into thinking "it's a tougher problem than I though". Other times, though, either I learn something, or end up making something that is much better for me to use. I would suggest at some time every programmer try build their own limited scope library if they find existing solutions do not meet their requirements.

okareaman 6y ago

I should write a manifesto about cooking for oneself instead of eating in restaurants, but then halfway through I'd think "why not both?

kstenerud 6y ago

While I appreciate the sentiment behind this, with experience comes a sixth sense of what should be rebuilt, and what is better reused/modified. Experience also brings with it an ability to scan through foreign code and get a "feel" for how usable it is. For example, I've chosen to replace one of the foundational data communication building blocks [1] because, after extensive research, the existing systems can't be modified to handle all of the general use cases I want handled. And it won't stop there, because I also have a number of additional requirements that HTTP won't handle (so there's also a new protocol in the works that will be based off this technology). If I could have simply modified an existing system to do what I want, I certainly wouldn't have spent the last two years on this! I've got plenty of other things demanding my attention... [1] https://concise-encoding.org https://concise-encoding.org

mjw1007 6y ago

Nowadays an approach that I find often worth trying is: - download a project in a suitable language that claims to do what you need - read its list of direct dependencies - implement your own thing using those same libraries - write your own replacement for any of those libraries that seem more trouble than they're worth. Indications for when this is likely to go well: - the top-level piece of software has grown its own configuration language - the the top-level piece of software has dozens of options for tuning its behaviour - the maintainers of the top-level piece of software have spun parts of it out as libraries, and they're being used by other people.

deleted 6y ago

[deleted]

SarikayaKomzin 6y ago

I like the idea of a “yeoman” programmer/engineer movement. It’s like homesteading except for consumer appliances/software — sustenance coding. I was happy to see a step-by-step guide to building a doorbell camera on the front page yesterday.

malwrar 6y ago

I believe the first step when creating something new aught to be answering honestly for yourself why existing solutions won’t work for you. Your time is valuable and much better spent building something no one else has yet. I was once heavily afflicted by NIH, but with experience I realized how much time I was wasting stubbornly trying to reinvent the wheel. That’s actually a great analogy if you think about it—-the original wheels were fashioned out of wood and are quite simple in concept, but creating modern wheels require s tons of specialized tools and knowledge to build. It doesn’t make sense to attempt this if I can just buy a premade one that suits my needs. That premade wheel also has the benefit of huge amounts of iteration in response to problems encountered over time, and I would probably need to replicate at least some of that in order to build something competitive with the existing solution. In the realm of code, using other people’s solutions when available lets me focus on the original problem I want to solve. It also allows me to minimize the amount of code I need to actually maintain myself, since typically there’s a group of people that are collectively much more knowledgeable than me doing that for free. If I ever do have a reason to know how the library works (patches, bug fixes, behavioral questions, curiosity), I’ve found it much quicker to figure out how the code works rather than write my own.

asddubs 6y ago
I would say "code it yourself, if it doesn't significantly slow you down". There's definitely something to be said for minimizing your dependencies, but if you're spending weeks implementing things completely tangential to what you're trying to do, you made a wrong turn somewhere. It's all about picking your battles, and I think you can go too far in both directions.
- nullsense 6y ago
  I'm personally starting to take the view of "sharpen your tools". That is, I'm fine with taking dependencies where appropriate, but I'm starting to contribute fixes and improvements to them as a way to derisk them. I think that benefits everyone.
bullen 6y ago
I think you mean re-implement the wheel, people often misuse the term re-invent the wheel. You actually need to change things for it to be called an invention: http://move.rupy.se/file/wheel.jpg http://move.rupy.se/file/wheel.jpg That said I always write everything from scratch, to me it's the meaning of life; If you are only using things you don't understand, you cannot (re-)invent anything. Today we also do not own anything, which makes the problem even worse. Rules for a good life: 1) own 2) understand 3) change!

forgotmypw17 6y ago

I agree completely. After dealing with the same sort of rot pattern in both software and services for years, I've set out to replace as much as I can with my own tooling. Mostly this has meant developing a hybrid blogging, forum, note-taking and writing, DAG database, information archiving and retrieval system and dogfooding it as much as possible.

keb_ 6y ago

I see the philosophy of "don't reinvent the wheel" taken to extremes in the React world, and before that, in the jQuery world. There is simply a plugin/component library for anything and everything you need to do, so relatively simple applications have monstrous dependency trees because it's easier to `npm install` the whole kitchen sink and use the little bits you need, than taking some time to understand & implement a smaller, focused alternative that could live in a `util.js` file in your project. At least thanks to tree-shaking and bundler innovations, the end-users don't suffer from bloated bundle downloads, but your node_modules folder is still 600MB large.

bitwize 6y ago

In business this is known as the build/buy dichotomy. Best practice is to focus on your core competencies. Meaning buy unless the available solutions do not fit your needs or are cost-prohibitive. As always, it all boils down to cost. "Code it yourself" may make your programmers happy, and give them interesting work to do, but if it costs the business a big chunk of money they could have saved or put to more profitable efforts, it's a very bad idea.

mro_name 6y ago

awesome. There's indeed one sole reliable supplier that really cares. Sadly sometimes not as competent or available as you'd like.

ur-whale 6y ago

However attractive the proposition may be, there is one, tiny fly in the ointment: time Of which there isn't much to go round, and very much of which would go down the drain if one were to follow that philosophy to get things done. Oh, and ... there's also all those pesky people who don't really know how to code.

kissgyorgy 6y ago

There is a huge missing point which overweights everything else; it's really expensive (in time or maybe in money) to develop your own software even if you are a good developer.

jaaron 6y ago

First: If the code is for you, and for you exclusively, go ahead. If you're writing code as part of a team for a customer, then it isn't for you and it's whole purpose is to solve the problem at hand. Secondly: The primary issue I have with a NIH code-it-yourself approach is that it doesn't scale over time. Professionally, over two decades, I have seen several teams go through a technical evaluation and decide, in the end, that no open or closed source solution exactly fit their needs. So they coded it themselves. Fast forward three to five years and everyone regretted the NIH approach. Those open or closed source solutions had matured and easily surpassed the home grown feature set, which still required a team of engineers to invest in. There are exceptions, of course. Sometimes you have to build it yourself. But more often than not, it's much, much more effective to let go of your ego and collaborate with others, particularly on open source solutions in which you always have the option to fork the codebase and bring it, effectively, in house. Generally, I find those that strongly advocate for NIH overly discount the long term costs of maintaining software.

twblalock 6y ago
> Fast forward three to five years and everyone regretted the NIH approach. Those open or closed source solutions had matured and easily surpassed the home grown feature set, which still required a team of engineers to invest in. This is the root of the problem: a small team generally can't keep up with an open source project over time. The NIH approach works well at larger companies who can dedicate a lot of engineers to working on in-house infrastructure projects full time. At smaller companies it is a distraction from building the core product.