9

The company I started working at about 6 months ago has no "standard" or "default" technologies for web application development.

The company is fairly new to hiring developers, so there are no formal standards or guidelines set out for them, and people are steadily joining as the company expands.

When a new person joins and they have to start a project, they use the technology that they know best to make the web app, rather than having time allocated to learning company standard technologies. As a result, we use Django, Flask, Node.js, ASP Classic, ASP.Net Core and then also one of Angular, Blazor, Razor Pages, Razor, React, Vue.js and HTMX. All these technologies (and more) in a team of about 10.

This means that we have issues changing people between projects, and when people leave, it causes a headache because e.g. no one else knows Django, we lost "the" Django developer. It also means we can't reuse code between projects, we are constantly building and rebuilding.

We have tried to standardise in the past, but it results in arguments about whose technology choices are going to be adopted and who has to learn stuff over again.

I understand the term "use the best technology for the job" - but this is constantly the same job, different technologies.

I am an intermediate developer at this company. What could I do to help solve this problem?

5
  • 2
    10 people must have some form of leader right? Are they technical? Feb 21 at 8:05
  • 1
    They are technical, yes. I think they acknowledge the problem, but are worried by the fact that discussions about standardising result in disagreements. Everyone (including myself to an extent) thinks "we need to standardise, so long as the standard is my technology choice."
    – Eoin
    Feb 21 at 8:13
  • 1
    The question that is supposedly the duplicate of this one seems totally unrelated, and also closed as a duplicate itself. Disagree with the closure on that basis. Feb 22 at 7:15
  • This is why CTO's are needed. Feb 25 at 21:57
  • 1
    The duplicate is only partially similar in my opinion and is itself closed, I've reopened this question.
    – Kilisi
    Mar 3 at 13:37

2 Answers 2

24

I think they acknowledge the problem, but are worried by the fact that discussions about standardising result in disagreements.

This is a leadership problem. Pure and simple.

The leader thinks the disagreements are a bad thing. They are not. Disagreements are fine, but at the end of the day, the buck stops with a leader that may have to make a decision if consensus can't be reached.

Even if disagreements are a bad thing, a leader does what they must do. If you lose 5 developers because they are so inflexible that they cannot pivot to a mandated technology stack, that's great. You've gotten rid of 5 people that will slow down the progress of the team. If you are hiring at a steady rate, that shouldn't be a problem.

I can tell you there are experiences that graduates simply have not been exposed to. They may never have experienced incompatibility across tool-chains, or the Django situation you mentioned. They simply lack the experience. Which is why leaders do need to step in and be firm.

In terms of what you can do, well, you can encourage the team leader as much as you can. If they lack the spine to do what they must, I don't think it's likely there is going to be much change without buy-in from your peers.

4
  • 100% agree. I am currently at a place that is making a painful transition. The previous senior developers all worked in their own way on their own stack. They've all left just before I joined and the new tech lead, myself and others are trying to pick up the pieces. The fault lay with the old technical manager. He treated these guys like rock stars and wouldn't set constraints on them. Frankly their code isn't wonderful and they've left a mess.
    – Dustybin80
    Feb 21 at 9:59
  • 2
    I assume you have never worked in a startup or a flat org. Flat organisations don't have leaders. We have projects that we do, usually in very small groups. We work on them either in isolation or maybe with another internal or external small consumer of those services. We usually work in very close connection with the end recipient of the services so whatever we do is usually vetted by the end user. Thus the need for a formal leader is not there. OP doesn't know what he wants IMO. If he feels the need for standardisation, then maybe a flat org is not for him.
    – BoboDarph
    Feb 21 at 10:24
  • 2
    @BoboDarph It's clear the nature of the work is not what you've described. Feb 21 at 11:32
  • This is an important transition, because it's the first time people will have to give up some of their independence to function as a team. How it's handled will make a big difference to how well the future, bigger, changes work. Feb 21 at 17:34
2

To add to Gregory Currie's excellent answer (or amend it), the tech stack does not have to be dictated top-down by a tech lead or team lead. It can be grown organically or democratically by the team. I once had a situation where we had a tech stack that was based on C#, but as it turned out the company had recently hired a whole bunch of Java developers (myself included) and the number of Java developers outnumbered the number of C# developers. When we went to rebuild our application, we decided to use a Java-based stack, because that's what the most people knew.

In the short term you may lose some people, but then you can hire more specifically for the stack you are using. That said, you want to make sure your stack is reasonable; you can decide that you have a bunch of FORTRAN developers at your company so you want to use a FORTRAN-based stack, but you're going to have a hell of a time hiring if you try that. Make sure your stack is reasonable, then unify it; everyone who wants to leave can leave, everyone who wants to stay can learn the new stack, and everyone who gets hired gets tested on that stack during interview.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .