3 ms·

.. This would make sense if it worked. There's a fine line between "not-developed-here syndrome" and minimalism-as-you-mention-it. If you can account for all t

.. This would make sense if it worked. There's a fine line between "not-developed-here syndrome" and minimalism-as-you-mention-it. If you can account for all the problems with the basic functionality the original big library tried to solve, this might work. But, if you're rediscovering all the problems again, and trying to solve them again, it's probably not the best use of your time. Further, if something is big enough to become a norm (like Disqus for comments) - creating yet another sign-up form for comments has enough friction to discourage at least me from commenting. (And the one on this blog is broken). I'm not saying your approach is wrong, but there's pros and cons to both, which don't seem to be captured here.

blowski 7y ago
An example of your point is ORMs. I’d much rather work with the bloat of Hibernate than any of the in-house ORMs I’ve seen.
anderspitman 7y ago
I think the key is having someone on the team experienced enough to estimate how much time to spend experimenting up front, and to recognize when things are getting into the weeds.
tipiirai 7y ago
There is indeed a fine line between NIH and minimalism. They have a strong correlation. You have to compromise between unnecessary features/bloat/crap or simply do it yourself. It's often surprising how easy it is to make something from the scratch. Hence NIH.
- hinkley 7y ago
  It's not that fine a line. There's tons of space in the middle and I find a steady supply of coworkers who love to write code and hate to use libraries who never bother to understand half of what the libraries they do use are capable of. I may be slightly unusual in my habit of trying to find new uses for the tools we already have, but I'm not abnormal. This is something mature people should be doing as a matter of course. This "everything sucks (from my myopic viewpont)" thing is like a bizarre form of learned helplessness. And I say that as someone who complains a lot about the quality of tools and libraries. Only about 10% of the time do I think that means we should write our own. 40% we should pick a different tool, and half the time we should try to convince the author to fix the worst aspects (when the problem is deeper than a PR can address). Code you wrote is easier to understand for you. Of course you're going to be more productive with your code but what about everybody else? Are you making any compromises for the comprehension of others? Do you remember nothing about middle- and high-school coaches complaining about 'ball hogs'? The optimists think all of their code is amazing and bug free and hence cheap. But it costs everyone else time, respect (either for you, or themselves), but perhaps most importantly, resume material and independent support options. You are hijacking the project to fluff your own ego. For me, the worst quartile of my jobs have been NIH that turned into codependent bullshit drama, and it causes a pretty intense histamine reaction (as is evidenced in my phrasing in this comment) for me with people who are not self-aware enough to allow at least the possibility that maybe 50 people who have been thinking hard about a problem for five years are better equipped to solve it than you can in a week of bravado, followed by months or years of dodging responsibility for the problems you created by substituting your judgement for the rest of the team and the entire Internet. Just get over yourself and be a team player for once in your miserable narcissistic life.
  - volument 7y ago
    I agree — there's tons of space between "everything sucks" and "bloated stuff sucks". We use libraries a lot, but often less is more.
  - downerending 7y ago
    This can truly cut in either direction, and one of the benefits of long experience is learning to judge the over and unders on what is often a crucial educated guess. Certainly, though, it's disastrous to assume that some existing library/product/whatever is going to be superior to home-grown, just because a lot of people use it, there's a big company behind it, or etc. That piece of software was written to cover a certain area of design and business space, and that may not intersect very well with the design and business space you need covered. For myself, I do start with the hope that I'll be able to avoid writing some big chunk of code (by using some existing piece of software). But I'm very wary, as external software comes with costs, even if it's "free".

blowski 7y ago

An example of your point is ORMs. I’d much rather work with the bloat of Hibernate than any of the in-house ORMs I’ve seen.

anderspitman 7y ago

I think the key is having someone on the team experienced enough to estimate how much time to spend experimenting up front, and to recognize when things are getting into the weeds.

tipiirai 7y ago

There is indeed a fine line between NIH and minimalism. They have a strong correlation. You have to compromise between unnecessary features/bloat/crap or simply do it yourself. It's often surprising how easy it is to make something from the scratch. Hence NIH.

hinkley 7y ago
It's not that fine a line. There's tons of space in the middle and I find a steady supply of coworkers who love to write code and hate to use libraries who never bother to understand half of what the libraries they do use are capable of. I may be slightly unusual in my habit of trying to find new uses for the tools we already have, but I'm not abnormal. This is something mature people should be doing as a matter of course. This "everything sucks (from my myopic viewpont)" thing is like a bizarre form of learned helplessness. And I say that as someone who complains a lot about the quality of tools and libraries. Only about 10% of the time do I think that means we should write our own. 40% we should pick a different tool, and half the time we should try to convince the author to fix the worst aspects (when the problem is deeper than a PR can address). Code you wrote is easier to understand for you. Of course you're going to be more productive with your code but what about everybody else? Are you making any compromises for the comprehension of others? Do you remember nothing about middle- and high-school coaches complaining about 'ball hogs'? The optimists think all of their code is amazing and bug free and hence cheap. But it costs everyone else time, respect (either for you, or themselves), but perhaps most importantly, resume material and independent support options. You are hijacking the project to fluff your own ego. For me, the worst quartile of my jobs have been NIH that turned into codependent bullshit drama, and it causes a pretty intense histamine reaction (as is evidenced in my phrasing in this comment) for me with people who are not self-aware enough to allow at least the possibility that maybe 50 people who have been thinking hard about a problem for five years are better equipped to solve it than you can in a week of bravado, followed by months or years of dodging responsibility for the problems you created by substituting your judgement for the rest of the team and the entire Internet. Just get over yourself and be a team player for once in your miserable narcissistic life.
- volument 7y ago
  I agree — there's tons of space between "everything sucks" and "bloated stuff sucks". We use libraries a lot, but often less is more.
- downerending 7y ago
  This can truly cut in either direction, and one of the benefits of long experience is learning to judge the over and unders on what is often a crucial educated guess. Certainly, though, it's disastrous to assume that some existing library/product/whatever is going to be superior to home-grown, just because a lot of people use it, there's a big company behind it, or etc. That piece of software was written to cover a certain area of design and business space, and that may not intersect very well with the design and business space you need covered. For myself, I do start with the hope that I'll be able to avoid writing some big chunk of code (by using some existing piece of software). But I'm very wary, as external software comes with costs, even if it's "free".