5
gevan
3y

Given an opportunity to develop an application for R&D. What do we do as a team? Let build it exactly the same way our current stack is built. (This app won't actually be used for anything useful, just an exercise for a fun R&D task)

It still amazes me with the number of developers that literally have the mindset, let's just do what we know & don't want to learn anything new.

Let's showcase new technologies? No. Let's create a serverless application? No. Let's create some microservices? No. Let's wrap the application in a Docker container so we can easily spin it up? No. Let's have multiple services that sit behind an API gateway? No. Let's for fucks sake at try a different design pattern? Why would we do that? Can we do anything differently? No.

No innovation, nothing - it just blows my mind. Everyone seems to think that the way the stack is built is how every application is. Sorry but a huge monolithic application that can't scale isn't how the other half live...

I don't know why the lack of wanting to try something new bothers be so much, but it does.

Had a real opportunity to showcase some cool tech, design patterns, new services in the cloud. Show not only other devs but upper management that there are alternative ways to develop. It's not like anything that I put together was "new or shiny" - I just wanted to do anything... Anything that isn't how currently do things.

Full disclosure, I'm not a great Dev - I'm pretty dam average but I'm always willing to try new techniques or approaches.

Comments
  • 1
    Is there a business case for using / exploring new technologie ?

    Will it bring money to the company ?

    If answer is NO, then using the current stack is a good decision.

    We don't code "just for code" we code to make money. If your "R&D" takes 5 weeks on a new tech and can't bring in money to justify these 5 weeks, it's good to not go down this road.
  • 3
    @NoToJavaScript thanks for replying.

    The application that we've decided to build, will be iterated on after the R&D sprint and could potentially be used by all the dev teams.

    Will it bring the company money, definitely not - however, it will value In terms of productivity for our team at the very minimum.

    I suppose, what I'm struggling with is why we don't use this time to explore other ways to develop the app. I don't understand why we'd copy an approach that is being overhalled in our stack - I see it as being lazy and devs not wanting to learn anything new.

    Maybe I'm just being naive?
  • 1
    I know I'm being a bit grumpy, I just think it's a great opportunity to showcase some cool tech.
  • 2
    Genuinely feel better for ranting a bit. Think I might need to do this more often.
  • 2
    @gevan Wel, here you go. That’s your case :

    The dev will save 30 minutes a week to X number of people. Multiply these numbers, add salary these people are paied (You probably don’t have access to this last info) and it transforms in an amount of Money. Present it and it should pass.
  • 1
    @AtuM

    As someone being a part of a Startup from ground up, I agree 100%.
    I designed the system in a cloud way. Not only cloud, but “maintenance free” way (meaning: no containers, no VM, only using PASS for everything).
    With a bit of retrospective on the last 7 years, PASS is still way to go for me. So much “shit” is just handled for me. ISO 27001 ? We are at 85%. Without making any effort.
    No updates, no VM maintenance, no versions. It’s fucking easy and reliable. (Fuck I sound like a seller at this point).
    The downside? Price. And even here, it’s not as expensive as having a sys admin or a network guy full time.
    Fuck in 7 years I never even touched firewalls settings, they just “work out of the box with recommended settings”.
    Now, we are at the stage were we want to “bend” these “recommended settings” and I fight to NOT do it.
  • 1
    Anyone that says innovation is a waste of time is wrong, I forgot the quote but system atrophy and processes die out or become less effective as needs and scale changes. Anyone that isn't innovating is actually on the decline simply by doing nothing.
  • 1
    I wouldn't say the other devs are lazy, I'd say they are delivery oriented.

    If you're focused on making a product, you build on reliable technology that the team is familiar with.

    Advantages are:

    -delivery speed

    - less error prone system with less bugs

    - cheap

    Disadvantages:

    -building projects with potentially less secure more outdated tech.

    You're more evolution oriented. You're trying to move things to the next level, you're design oriented.

    Advantages:

    - opens potential (not guaranteed) new venues and options for future projects

    - opportunity to research ways to fix old common problems in the usual delivery cycle and possibly speed up future development

    Disadvantages:

    - slow to deliver, requires a lot of research from everybody on the team

    - lack of common patterns the team can use and lack of people that can maintain the system if the original team leaves

    - expensive

    Both approaches are tools to be used at the right time by the right people
  • 1
    @NoToJavaScript well if it's R&D to explore new options it could be good to explore new ways. Another aspect is training of the people aka competency development(? Or something like that) which is an invest the company makes in its employees for them to be better and in turn be better employees. I suppose the details are important in this case
Add Comment