How affected are you by the "Not Invented Here Syndrome"

[Forseth]

So I have mostly been making firmware and solutions for robotics systems and always have made everything myself. this has been my reality for the past 15 years. now that I am a bit more free in my programming pursuits I find that I have a hard time dealing with other peoples code. not beacuse it is bad but I am so etuck in my own ways of doing it.

At the moment I am struggling a bit with phoenix as I sometimes feel I have little control over it. This is almost guaranteed due to my lack of knowledge with it.

TL:DR
Its hard for me to use frameworks , how do you deal with “Not Invented Here Syndrome”

[jwarlander]

As long as the framework or library / depencency is reasonably well documented, I don’t personally have a problem with it most of the time… but on the other hand, I usually want to minimize the number of dependencies in use for other reasons.

A rule of thumb for me would be that if I use only a small part of a dependency, or if it’s a trivial one, it’s probably better off implemented locally so that I’ve got full control over the API, implementation details, etc.

However, if it’s going to be several weeks or months of work just to do something that someone else has already done, or if it’s a problem in an area I know little about and that takes some serious effort to understand (not to mention understand well), I’ll go for the dependency, trying to learn what I can and use it efficiently.

I can certainly see where you’re coming from though… it’s always hard to let go of control!

[sotojuan]

Phoenix is barely a framework—just a bunch of Plugs pre-written for you bundled with some third party libraries like Ecto.

If you want to learn how things work deeply then go all NIH-mode and write a web app with just Plug. I don’t recommend it for production use but it could be great for learning/side project. Then you’ll feel more control over things as you know how they work!

[Crowdhailer]

Or go even further into NIH-mode and write a web app without phoenix plug or cowboy, like I am doing.

I deal with it by trying to do as much Not invented here as possible on personal projects and then you find out how hard things are without the libraries. If it wasn’t that hard to achieve something without the library then NIH syndrom is not a problem. It’s all balance.

On the topic of phoenix/plug I’ve heard a few people say phoenix is barely a framework. Maybe but both make thorough use of macros and have a not insignificant amount of indirection

[bobbypriambodo]

Old Uncle Ben once said, “With great power comes great responsibility.”

I like to think that every line of code you write is a debt. It’s cool if it’s for personal projects or any project that you will maintain yourself forever (or until you dump it). But for long-running projects, projects where you collaborate with people, the core technology of someone’s (or your) business, most of the time it will be too much debt to handle. You owe the users of your code (be it your peers or your future replacement) many things: documentations, tests, code clarity, maintainability, etc.

Using libraries, other people have taken parts of the debts upon their shoulders, so you don’t have to.

[ibgib]

@bobbypriambodo

I like to think that every line of code you write is a debt.

This is one of the scariest things I’ve ever heard anyone say about code. I write code out of , not obligation.

[bbense]

If you have to maintain the code in production, it’s the only sane way to think about it. Or as I like to phrase it

“The only good code is deleted code.”

[ibgib]

@bbense

If you have to maintain the code in production, it’s the only sane way to think about it. Or as I like to phrase it

“The only good code is deleted code.”

I totally get wanting to have good code in production with all of the good qualities, such as maintainable structure, self-documenting code with sprinkles of comments for kluges and hacks for time crunches. I’ve seen and had to maintain ugly code in production as well. But this does not make all code intrinsically bad, otherwise what does “elegant code” actually mean?

To me, your quote “The only good code is deleted code.” sounds clever but would be treated as hyperbole to teach a lesson about being lean and concise. Thinking of “each line of code as debt” I think may be a misapprehension of the concept of “technical debt”, which is not talking about all code, but rather the additional work later on because a lack of investment earlier in code that makes it more maintainable.

[bobbypriambodo]

@ibgib

This is one of the scariest things I’ve ever heard anyone say about code.

Ahaha, indeed, as I Iooked back it was really negative. I also love to program (and Elixir keeps reminding me of that fact! ), but if the result of it involves others… the responsibility is quite huge.

[OvermindDL1]

A few things…

1. I love looking up libraries to use so I do not have to write them, I am inherently lazy and the less I have to write and maintain myself the better.
2. I also have this odd habit of needing to do things the library authors did not expect.
3. I also have this odd habit of needing functionality of libraries that are now dead…
4. Thus I’ve also got this odd habit where I fork and maintain copies of dead libraries (often internally and not on github or so, I just kind of copy them in to my project in special locations, I know, I’m bad…) to fix the bugs they have and add the features they miss.
5. I also have this odd habit of needing functionality that no one else has written and released (publicly anyway), so I end up having to write a lot of really basic simple things (heck, look at how simple my released permission_ex library is, how did that not exist before?!), most of which I do not release because I do not like releasing things, even simple things, without documentation (my OverECS project was released only because someone wanted an example of how I do ECS projects in my own projects, and since I’d never library’ized it before I whipped up an incomplete example to show how it was done, there are practically no good ECS systems out, at least not when I wrote that, ‘specs’ for rust is pretty good though, one of the best I’ve seen thus far anyway).

[bbense]

Elegant code is a myth. I’m not saying that there isn’t code that is fun to write or interesting to read, but the fundamental fact of production is that the world changes and your code doesn’t. Eventually the world will change enough to turn the most elegant code into a useless pile of symbols.

The only useful quality of code is how easy it is to delete and replace, because if you’re not doing that, then your code isn’t being run.

[ibgib]

@bbense

The only useful quality of code is how easy it is to delete and replace, because if you’re not doing that, then your code isn’t being run.

I think perhaps this is a bit of shadow boxing, or a mismatch in terms, because as I see it - “being easy to delete and replace” is what makes it elegant. Hard to delete code is the code that exists all over the place, is not DRY, is not documented, is badly designed, etc. Perhaps you dislike the term “elegant”

[Qqwy]

Most people do not think (often) about this, and I think the same thing is true about ‘elegant code’: Nearly all the nice code we write is code we marvel at ourselves, but neither our colleagues or our customers will ever know.

It is much easier to see the oversights than it is to see the good parts. Maybe that just is the way we are trained to think in today’s society.

It also very commonly happens that code that I find elegant ends up being too hard for my coworkers to understand …

---

@OvermindDL1: The ‘habits’ you describe are not very ‘odd’, in my opinion: The fact that you are doing things that nobody did before probably means you are doing nice, new, innovative things. Also, the sheer fact that the infinity of creatable computer programs is a really really incredibly large infinity means that it very easily happens that you are looking for something that is different.

---

@bobbypriambodo Yeah, debt is a very negative term. I do agree though that you are responsible for the code you write.

---

Back to the topic at hand:

A great saying from the game development world (I’m paraphrasing here, and unfortunately I do not remember who originally said it) is:

You can either make a game, or a game engine, but not both.

And I think this is very true. If you don’t want to get bogged down in a project that is too large to maintain, it is important to focus on something. You can either build something that is a nice general (partial) solution for a large set of problems, or perfectly solve a single problem, but not both at the same time.

That being said, it is hard to work with other people’s code. What helps in Elixir is that the language already nudges people in a direction of creating readable and maintainable code, which overlaps with what I like to see in code.

[andre1sk]

This is a two edged sword to look at what happens if taken to the extreme one only needs to look at js/npm ecosystem.

[OvermindDL1]

@andre1sk

This is a two edged sword to look at what happens if taken to the extreme one only needs to look at js/npm ecosystem.

/me twitches…

[peerreynders]

[quote=“ibgib, post:6, topic:2775”]

@bobbypriambodo

I like to think that every line of code you write is a debt.

This is one of the scariest things I’ve ever heard anyone say about code.[/quote]

Chad Fowler’s ‘Kill “Microservices” Before Its Too Late’ talk (Impermanence is the key to a surviving system) caused me to run into content like this:

Edsger W. Dijkstra (1988): On the cruelty of really teaching computing science

My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

Alan Cooper of Cooper Interaction Design sees planning as key to downstream dividends (2001-06-14)

One of my assertions is that code is not an asset. A lot of companies say their job is to maximize the revenue from our code base. That reflects a kind of an Old World, industrial-age thinking.

Tim Ottinger: Code is a Liability (2007-04-17)
Eric Lee: Source Code Is A Liability, Not An Asset (2009-03-11)
Jeff Atwood: The Best Code is No Code At All (2007-05-30)

Thomas Figg: Write code that is easy to delete, not easy to extend. (2016-02-13)

• reddit discussion
• Hacker News discussion

Off topic tangent:

@OvermindDL1

@andre1sk

This is a two edged sword to look at what happens if taken to the extreme one only needs to look at js/npm ecosystem.

/me twitches…

OK, I get the issues surrounding callback hell - BUT is it just me or does a significant portion of the JavaScript community have an unhealthy attachment to nested, multi-line, inline anonymous function expressions which continues even when they are using promises? There are other ways to organize this kind of code. And the style completely ignores the decades old sentiment‡ behind the arrow anti pattern and that code should be no larger than James Lewis’s head.

‡ Edward Yourdon, Noam Chomsky, and Gerald M. Weinberg (1986): Managing the Structured Techniques: Strategies for Software Development in the 1990’s

[andre1sk]

@peerreynders

OK, I get the issues surrounding callback hell

It was more about dependency hell
async/await and promises kindah solve the call back hell issue.
create-react-app fresh app 700+ dependencies with 20,000+ files

[peerreynders]

I knew what you meant.

I was just fielding yet another example that could lead to the perception that some parts of the JavaScript community insist on independently re-discovering mistakes that have already been clearly identified by earlier software practitioners as poor practices - which can only be interpreted as flagrantly ignoring already existing software development wisdom.

… anyway while the are some Phoenix related JavaScript libraries, this doesn’t directly relate to Phoenix.

[andre1sk]

this relates to the topic of NIH as an illustration of the polar opposite

[sotojuan]

Most of CRA dependencies are Babel… which is not “NIH” as it’s a to-ES5 transpiler that doesn’t have many alternatives. You could argue about Webpack, but I find it to be very different than Gulp, Grunt, and other Make-replacements as Webpack is essentially a replacement for the browser asset pipeline that lets you have a lot more control over it. The problem is the JS community’s love for small modules, the lack of a standard library, and the way npm works/installs stuff.

If we had to install each OTP Behavior and STL module as a Hex package (and if Hex was poorly designed) we’d have similar issues.