dwyl / technology-stack

🚀 Detailed description + diagram of the Open Source Technology Stack we use for dwyl projects.
287 stars 26 forks source link

How to avoid "Not Invented Here" ? #38

Closed nelsonic closed 2 years ago

nelsonic commented 7 years ago

Most technology-based organisations/companies suffer from https://en.wikipedia.org/wiki/Not_invented_here syndrome... How do we avoid it? image

https://www.google.com/search?q=not+invented+here&tbm=isch

relates to #18

samhstn commented 7 years ago

I really can't think of good ways to avoid this other than making everyone aware that it is a typical problem in technology companies.

@nelsonic has this been a stumbling block in the past or are you concerned for it happening in the future?

nelsonic commented 7 years ago

@shouston3 thanks for replying. This has been a problem in every company I have worked in. To the extent that the problem has been parodied by several cartoonists and there's even a comic that has the expression as its' name: http://notinventedhe.re/on/2009-9-22 ... all organisations have this problem. it's a social problem. Think about it in the context of sports. People support a team that is clearly worse for no reason other than "it's my team"... not naming any names (cough! Nottingham Forrest...!) 🤣

the only way we avoid it is by having open conversations about other potential technologies where the facts vs. hype, assumptions vs needs, cost vs. benefit are clearly laid out by the person/people making the proposal to use something different from what the team is already/currently using...

We need to follow a process for suggesting new technologies/tools/practices to ensure that we don't have a deluge of "have you tried XYZ latest framework, can we re-write everything again...?"

I've gone through several programming languages, frameworks and "styles" and have found flaws in each of them. Count yourself lucky that you aren't learning/coding in the "dark ages" before Git/GitHub, Testing and single-command deployment... 😉 I'm not one of those "old timers" (which is mid-thirties in our industry) who is nostalgic about the "good old days"...

"back in my day we didn't need a Virtual DOM SPA with Isomorphic Fetch, to build a website, it was just plain'ol HTML+CSS and a bit of ASP or PHP..."

I've always embraced new tools/technologies because ultimately our mission (or "job" if you prefer) is to make something reliable that solves the requirements of the end-user in the most sustainable and productive way.

I can go into a whole history lesson but will reserve that for another time. The tl;dr is: we need to

the thing to note is: No "End User" ever asked a developer to use "XYZ Framework" for the app. all the people using your app want is for it to be reliable/fast/error-free/secure and they don't care how you get that done!

We as "creative technologists" have the right/obligation to learn new things which will help us to deliver the product/project in a more effective way. or for example someone could suggest: if we use "ABC Language" we can save 60% on our server costs because it takes advantage of multi-core better or handles more concurrent connections, then that's worth considering because it saves money for all our projects and any by using that tech (that saves money) we can gain a "competitive advantage" ...

This always needs to be weighed up against the switching/learning cost of something completely new...

If I can say just one more thing on this is: we need to eliminate the mental barriers to learning new things personally first, then as a team we can be a lot more open-minded. ❤️ ✅ 🚀

nelsonic commented 7 years ago

@jessitron captured it way more eloquently and succinctly: image https://twitter.com/jessitron/status/617328825131737088

Adventures in Elm • Jessica Kerr https://youtu.be/cgXhMc8M4X4 😍 If you haven't watched it, add it to your "watch later" list now! 👍

nelsonic commented 2 years ago

https://github.com/dwyl/hq/issues/566