Convincing a client to use Phoenix over other popular web frameworks

A lot of the arguments given are I think just slight rewording of the same thing: “we want to make sure the work keeps going regardless of who is doing it, and for that we want something that’s easy to hire people for”. And it’s sprinkled in with way-too-vague statements about a tech stack being able to stop them from doing business – whatever that means (and that “feat” is achievable with any programming language, Elixir included, because it depends on the quality of the staff and not the tech stack).

It seems they are just trading one risk (“we might not be able to hire a new dev if another quits”) for another risk (“let’s pay a fortune to an army of Java devs but at least we can replace anyone at any time”). Both are risks and I don’t see why the second one is preferable to the first one. Financially it also doesn’t seem to make sense either; you objectively spend more money in the latter case.

Since they are willing to throw money at the problem they might as well overpay their Elixir devs and promise them various benefits if they stay longer, no?

I don’t mean to be demeaning. But I see bias and inclination to prefer one class of risks to another. I remain skeptical that this is an objective assessment. It looks like preferences written in a perfumed language to me.

1 Like

I don’t think there is such thing in this space. Policies in organisations are scar tissue from previous wounds. Similarly, any risk assessment is undertaken by people with their own histories and battle scars. I’m particularly sensitised to concurrency related issues in .Net as I have seen many, many person-years of lost productivity associated with that. Incidentally, a completely different and sane concurrency model is what drew me into Elixir-land in the first place. I’m also sensitive to resume-driven development as I have seen a lot of expensive over-complication in order to get the latest cool tech on the CV.

100% agree. I actually think, due to the pandemic, this is a worse excuse than before. It is easier than at any time in history to run a remote team and get specialist skills from anywhere on the planet.

But I can understand why others wouldn’t, based on how they may have been burnt in the past. Also, corporate IT & the consulting firms that advise them rely on big teams to justify big salaries for management.

It’s weird, too. Typical most common techs such as .Net, Java, PHP, JS where you can hire “anyone” seem to have way more opportunities for unskilled developers to shoot themselves in the feet and/or create impenetrable spaghetti. At least in Elixir, if you have messy code, you can IO.inspect either side of a function call and have a fighting chance of understanding what’s going on (unless it’s macros…).

1 Like

I totally agree that there are many reasons Elixir/Phoenix can be an objectively much better fit for projects. I was just playing devil’s advocate. My comments were based on the explanation that was used in the first post. There is no reasoning why it benefits the business. There are just generic statements which are very easy to counter. There’s nothing objective about it. Even ‘easy to learn’ might not be the case depending on who is doing the learning. Functional programming might be completely new to them. I’ve seen developers struggle with it.

I love new and different technologies. I’m also someone who can switch between technologies very easily. But iimho as a senior developer it’s also my responsibility to be objective, look at the type of project, look at the people around me and see things from the business side. I also have to be aware of both the pros and cons of the technologies used. I’ve seen countless times where something is being used because it’s new and shiny, not because it benefits the business. Many developers also tend to ignore the negatives of the technologies or what is required to support it in production (deployment changes, support training and so on). So yes, I will push back and ask tough questions. Not to prevent change, just to be sure there is solid reasoning behind it and that it will actually benefit the business.

2 Likes