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 '18 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 '18 at 11:44
  • 1
    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 '18 at 13:17
  • Angular? What is this, 2015? A good framework helps eliminate the need for tribal knowledge like you have with your current systems. – Trevor Jan 24 at 18:57

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.

  • 5
    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 '18 at 2:15
  • 7
    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 '18 at 15:01
  • 3
    @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 '18 at 15:27
  • 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. – Lycan Feb 20 '18 at 17:07
  • 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... – Conor Mancone Apr 2 at 12:07

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).

  • and the cost of redeveloping the systems – Neuromancer Feb 19 '18 at 12:45

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.


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 '18 at 0:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.