I think I initially agreed to use a new framework, but after risk analysis and audits on current software, I am hesitant to use a new framework (eg Angular) for critical systems.

  • The current development stack can be supported by both myself and the employee.
  • Hiring "new framework" staff would cost a lot, we don't have the budget to hire these developers (I am aware this employee wants to leave anyway).
  • If we use a new framework, I would have to learn it (I don't have the time or the interest).
  • The framework already has had non-backwards compatible update, I am concerned if it happens again.
  • External auditing requirements are high, "paper work"/validation heavy, so I would rather manage as simple system / stack as possible, easy to maintain.
  • Even the visual theme, I'm saying to stick with our 5 year old "bootstrap" one, there's no point to add a new one.

I've made them aware of this but they still don't get it. They are a better developer than me, and they say that "new framework" will allow "faster" development. But from my point of view, solid delivery and maintainability is more important. Especially if staff will change.

I've let them develop some apps in "new framework" (dashboards/widgets) as I understand there should be some career dev, but for critical systems it's too risky.

Is the developer just concerned for themselves and not the team/project? If they are not happy here, should I push them to leave?

By "fast" from his perspective is implementation, coding it and being able to adapt to future change requests - I see that. But for me it is not just the coding, we have testing and documentation, new bugs from moving to a new stack, etc. The old tools/current stack we have we have ironed out issues - it is "mature". With a new set, there will be new issues to resolve - just like when we first moved to the current stack, there were issues to resolve.

Update - I was told by this developer that what I was saying is bull***, loudly in the corridor, similarly in a communal area in front of people. I understand there is conflict, but is that a good way to deal with your manager or even someone you manage? It felt like dealing with a child/teenager. If I disagree with the COO, I'd sent him a few links and sources.

  • 1
    To make this a workplace question, what is your professional relationship? Co-worker, team leader, manager, company owner?
    – gnasher729
    Feb 19, 2018 at 6:49
  • 1
    You said your made a risk analysis and audits. Then didn't you give to the business men the costs and risk costs of changing of framework ? Business men are the one holding the money, if it ost too much, they won't proceed. Unless the developers can make themselves an audit to prove that it would cost less than sticking with the current solution, which I doubt if you can maintain that with two people.
    – Walfrat
    Feb 19, 2018 at 11:44
  • 2
    Good frameworks don't break backward compatibility in their LTS releases. Just security/bugs fixes that may pop up and generally speaking a good framework will have LTS at least 2-3 years and offer deprecation guidelines to upgrade to the next LTS release.
    – Dan
    Feb 19, 2018 at 13:17
  • 1
    @Trevor You can create tribal knowledge with any framework. Frameworks do not solve that problem.
    – Nelson
    Jun 25, 2020 at 6:46
  • It could be that they are feeling obsolescence pressures. I had a large team overwhelmingly pick a new framework on the sole ground that they didn't want to spend the next decade working on something 10 years old. The side-benefit was that we had candidates banging down the door to join our team because everybody heard it was the hot new thing. Was it technically the best decision? Maybe. But was it the right personnel decision? Yes. Ironically, it makes team members less likely to leave if they feel they are on the latest tech - even though it boosted their resumes.
    – Moby Disk
    Jun 25, 2020 at 18:51

6 Answers 6


Is the developer just concerned for themselves and not the team/project?

This is a common thing for business-oriented people to think. In my long experience it's never been true. Developers care about the system: the business depends on the system working, so they want to produce a quality system. They're also expecting to be asked for new things in the future, many times over a long period. Since they are the ones that have to actually implement the requests they are keenly aware of anything that will make it more difficult. The developer naturally tries to establish solutions to these anticipated problems. They're trying to prepare for business needs.

They are a better developer than me, and they say that "new framework" will allow "faster" development.

You quote "faster" here. I'm not sure if you don't believe the developer on that point or are doubtful of its value.

But from my point of view, solid delivery and maintainability is more important.

This presents a false dichotomy with faster. The developer is probably considering these things implied. In other words: currently we can provide solid delivery and maintainability. If we switch to the new framework, we can provide solid delivery and maintainability faster.

On the other hand you raise valid technical points. Switching platform is genuinely a large undertaking. I wouldn't do it lightly.

I propose asking the developer for specific pain points in the current system. Assume they have good reasons for thinking what they do and ask about them. Have they been forced to use ugly hacks that are piling up all over the system? Are they spending time creating capabilities that already exist in modern systems? Is the current system poorly structured and they have to fight with it to achieve things that should be easy?

If there are specific issues, what they want is to solve those issues. If switching platform is too much ask if they can suggest less drastic ways to solve them. They may have some ideas. Or you may find the problems really are significant and staying with the current system is the larger risk.

  • 8
    You write: "developers care about the system". Yes, I agree. But especially younger developers have maybe other priorities than more experienced developers. And the management and has again other priorities. I think we should not assume that they have all the same priorities.
    – Edgar
    Feb 19, 2018 at 2:15
  • 12
    I have certainly known developers who have been interested in exploring the new shiny because it was new and shiny, whether or not it was actually the right answer for the company. Still, the advice to ask about specific driving reasons is excellent.
    – Ben Barden
    Feb 20, 2018 at 15:01
  • 6
    @BenBarden I'll have to double your words. I've seen a fair share of devs that pushed forward new techs (and quite a few times, very old ones) just because it was what they liked, not what would be the best for the problem at hand. Learning new techs is good - forcing them over a problem without proper care isn't.
    – T. Sar
    Feb 20, 2018 at 15:27
  • 1
    After seeing so many business people failing to grasp technical implications of something and dismissing the developer in exactly these terms, I've become skeptical. When a dev talks about making something "faster" it's because the current situation is making it painfully slow. That's a business impact that business people are too often blind to.
    – user78094
    Feb 20, 2018 at 17:07
  • 9
    As a technical person who is currently cleaning up the mess of a developer who insisted on using the shining new things without considering their actual value, I would say there are definitely two sides to this coin. Some of the shiny new things he introduced are in fact quite helpful, but some were a big waste of time. It's clear that he wasn't giving the actual business needs much thought, so those things that did succeed seem as much luck as anything else... Apr 2, 2019 at 12:07

If you are the persons manager, then you make the decision. It’s nice if everyone agrees, it is important that everyone respects the decision.

You should make the decision that is best for the company. It is good to have code that can be handled by you if needed, or by a new developer without specialised knowledge. On the other hand, it is good to use a framework if it genuinely helps and isn’t just in fashion. Anything requiring to change your existing code is a negative. Having an enthusiastic employee who is keen to produce good results to prove he’s right is good. It’s your job to weigh up the pros and cons, decide what is best, and making the decision.


How about you create a list with pros and cons of the different frameworks together with everyone. It should include technical aspects what can be done or can't be done with the frameworks, how fast things can be done, stability issues, history (one framework is maybe stable, the other one is brand new and maybe still has some bugs) etc.

I think it's best to create this together with the team in more or less random order. Maybe the developers want to talk first about the good things about the new framework and later you ask them about stability issues, etc. At that stage it's just about collecting information.

And after that is done then you can look at priorities. I.e. for one project or one part of the project maybe the interface should look trendy and maybe that is easier done with the new framework. And for another part it is maybe more important that everything is 100% stable even if it takes longer, etc.

If you do this together with the team you should all come to the same conclusion which framework should be used for what.

But at the end of the day you are the manager and responsible for this. So it's your head if something goes wrong. You have to decide, best with the team but if necessary against their advise (after you all know the pros and cons).

  • 1
    and the cost of redeveloping the systems Feb 19, 2018 at 12:45
  • I fully agree, except that the OP should have the developer in question perform this work. Let them work out the pros and cons and give a presentation in front of the whole team, trying to convince everyone why their approach is beneficial.
    – Theo Tiger
    Jun 29, 2020 at 14:06
  • @TheoTiger: If you want to make that one developer look bad then do that. If you want a happy team then I am sure it's better to let the team work together and find out together what is best.
    – Edgar
    Jun 29, 2020 at 23:47
  • @Edgar Letting the team find out is actually part of what I was suggesting: If that developer has an idea to improve the development strategy of the company, let them make a pitch and have the team discuss it. If they can persuade everyone why their approach is good, fine. If not, they will get feedback on why their idea is not superior in every aspect and learn how decisions are being made in the company. Both are important lessons they could learn through this practice.
    – Theo Tiger
    Jun 30, 2020 at 9:51

Is the developer just concerned for themselves and not the team/project?

Professionals are always concerned about themselves and their careers, and if the project / team happens to align with that, all the better. That's perfectly acceptable. Your colleague wants to go somewhere where they use these new technologies, and probably pay a lot better than you do.

If they are not happy here, should I push them to leave?

You don't push someone to leave. You talk to them about their future career at your company, set expectations, hear complaints, and talk about how to better work for them as a manager. If the only way someone is going to be happy is by leaving for where the shiny and sexy tech is being used, that's something you have to intuit out of them, not something you tell them.

It sounds like you're already letting the dev practice his skills in new projects, and you've explained the reason why you don't migrate the sensitive system to newer tech. Maybe they didn't get it, maybe you didn't explain it properly. Make sure to stress that it has little to do with actual dev time, and everything to do with external pressure.

  • Actually, no - I'd say that as a professional, I'm always concerned about the project/team and if my careers/interest happens to align with that, all the better.
    – Gwyn Evans
    Feb 23, 2018 at 0:29

You have two issues which could be in conflict with each other

  1. Managing the "technical stack"
  2. Managing a technical person

Managing the "technical stack" is deciding what languages, tools, frameworks, and testing systems the company will use - especially for critical production work. No one developer should be allowed to change that stack. This is a decision that goes up the chain of command as it affects your company compliance and auditing. Many developers are not aware of all the costs that come into play. If your top management has not been involved prior to this, I recommend making a presentation to them of what the issues really are - why you have the current technology stack, what the costs are for making any change, and how you will present changes to them in the future. In short, you are pulling your whole management chain to back you up in your choices. "Developer, this is XYZ corporation's technical stack. It will be used on all critical software."

Now, once a company has made a decision on the "technical stack", it becomes an issue of dealing with a developer who wants to use a new framework. Certainly, such can be used for non-critical tasks in order to discover what the full range of costs might be. However, I recommend having a written process for evaluating new technologies that might be considered for critical production work. Again, the results of that evaluation will have to go up the chain of command with a cost / benefit analysis to convince the top management to change.

I say that after being a developer that hid new technologies into projects and used such things to try to convert management to such new technologies. I didn't know all the costs that I was trying to push onto the company. I was wrong. That is behavior that needs to happen not on critical projects.


As a software professional who's been in this business for ... (koff, koff, wheeze) ... "quite a while now," the basic situation that you are now describing is: "legacy systems."

For example – "my present employer has been manufacturing sofas for more than 85 years." When IBM first introduced the "System/36," they bought one. When "RPG" was the best language of choice, they wrote mountains of code using it ... and they still sell sofas!" (And: "those sofas are still comfortable – betcha you know someone who owns one.")

Thus – there is, and there always will be, "a dichotomy" between the technologies that we decided to use, and the technologies that today we would prefer to have used had they been invented yet. But we can never expect "new programmers" to understand this ... yet. 🤷‍♂️

You must log in to answer this question.

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