How do you go about introducing new technologies to your company/team?

Whether it’s writing the next API in another language or using a new framework/library/approach?

  • 0
    1. Make a Proof of Concept
    2. Tell the "more business" it guys what would be better with the new tool, language, whatever
    3. Bring it to the devs that are willing to do new stuff
    4. Let it spread
  • 1
    usually I just do it, otherwise we‘d still be using java 8😅
  • 1
  • 1
    aww thanks for thinking about me @Rememberme xoxo

    To answer OP's question it greatly depends on your working environment. Some shops are very much hesitant to try new technology stacks.

    If you are working on an established platform for the entire company in something like, say for example Rails and/or Spring and you want them to consider something like django for a service it might very well not happen. Specially if the entire department only has experience using the previously mentioned technologies and the cost of adoption would just be way too big. For this, size of company matters, skill level and personnel, and a lot.

    My strategy before being promoted to head of department was: find some utility that can be scripted with a small application that would otherwise take way too long in another stack. Think generating reports into simple excel sheets with Java, that shit sucks. But doing it in Python is absolutely possible.
  • 1
    @AleCx04 continued. So if you are in a position in which you can advice using another implementation that will be simple to package and distribute to the rest of the team, offer to do it in a secure testing environment, then produce it and bask in the results.

    I developed an LDAP/AD user porting and management tool for my institution in Clojure, because I wanted to test it out in a real environment. No one here knows clojure, and why should they? its esoteric enough to not have a lot of immediate advantages for most people. But I none the less wanted to try it. This task was mine mostly and it was only to be run by 3 people. So I built it, packaged it as a command line tool that will save them from doing retarded shit (as well as myself) and distributed it through or network.

    Plus side: It works blazing fast and does exactly what they wanted without having to pay for it from somewhere else.

    cons: Only I know how to change/maintain the code.
  • 1
    @AleCx04 continued.

    Those cons are far too great even though they seem small. I can say that I am staying here forever all I want, it doesn't take away from the fact that if I leave, our C#/Java/PHP developers will be able to get efficient enough in the language to properly maintain it (Clojure) and they would have to invest in external help. For big organizations (like mine) this is meh, but smaller shops might be hesitant. This is the main reason why people don't like the idea of building actual production ready products with different technologies, their strength lies inside of their current talent pool.

    find something small that can be made as a utility rather than a big product. Implement it, share it and explain it properly to the rest of your team, interest will come naturally and maybe eventually you will be able to focus in new stacks and build products using something that everyone else will be able to chip in to.
Add Comment