Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to avoid "Not Invented Here" ? #38

Closed
nelsonic opened this issue Jan 23, 2017 · 4 comments
Closed

How to avoid "Not Invented Here" ? #38

nelsonic opened this issue Jan 23, 2017 · 4 comments
Labels
discuss Share your constructive thoughts on how to make progress with this issue help wanted If you can help make progress with this issue, please comment!

Comments

@nelsonic
Copy link
Member

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

@nelsonic nelsonic added discuss Share your constructive thoughts on how to make progress with this issue help wanted If you can help make progress with this issue, please comment! labels Jan 23, 2017
@samhstn
Copy link
Member

samhstn commented Jan 28, 2017

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
Copy link
Member Author

@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

  • encourage people to try new things
  • document all our learning in readmes (preferably screen recordings when things are promising!)
  • only bring a proposal/suggestion to the rest of the team once we have tried it ourselves (don't waste other people's time linking to things you haven't tried and can't articulate the benefits of...)
  • have "mini projects" where we try out new things. or re-write something small in a new language to see if we can make an improvement on an existing thing.

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
Copy link
Member Author

@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
Copy link
Member Author

dwyl/hq#566

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Share your constructive thoughts on how to make progress with this issue help wanted If you can help make progress with this issue, please comment!
Projects
None yet
Development

No branches or pull requests

2 participants