Hacker News Reader

Comment by roschdal | Hacker News Reader

In my opinion, this is a case where a supplier (IT consultant company: Bekk) uses a non-standard unpopular technology, to implement a technical solution, for a customer who is state owned and has almost monopoly (Vy/Norwegian Railways). I suspect, the reason for this choice, is to lock the vendor in. For the customers of Norwegian railways, the results is a more expensive train journey.

View on HN

What's your evidence that train journeys have gotten more expensive in Norway due to this?

FWIW i am Danish and almost all of our public IT projects are done in .NET, almost always the reasoning is "more developers, more mainstream, less lock-in". Our IT projects are always hilariously belated and more expensive than budgeted. More often than not the same contractor (one of 5ish big corporations) keeps getting the same contracts from the same departments because they have pre-existing knowledge of the system they previously built (hint: this is lock-in). Now, the last part is changing somewhat due to EU tender rules, which I think Norway also abides by (they are not in EU, but are committed to complying with most EU laws)

Isn't being locked to one of five big vendors that do .NET a bit better than being locked to the vendor that does Elm, though?

The vendor lock-in is a good point... Isn't this risky for the customer? What do they gain over, say, a well-crafted React-TS SSR app, or Django or what have you? Do they really get an end-product that is so much more reliable? Is this cheaper or more efficient? What happens if there is a political fallout between the consultant and the customer, or if the customer can no longer afford them?

I mentioned this in another post. But Vy has their own developers, and the development teams here contains a mix of Vy and Bekk developers. As such, Vy has enough Elm experience to handle any future turnover.

The external consultant developers are incentivized to keep essential knowledge to themselves, in order to get new contracts later. The supplier's IT consultants (Bekk) don't share essential knowledge with the customer's developers (Vy).

We're working at the same location. On the same codebase. With the same access to our version control and issue tracker. There is full transparency. We even help Vy train their new hires.

We're incentivized to work this way because that makes the customer feel safe. Which is how we win contracts.

It might be that way where you work, but that's definitely not the case here.

In fact, I think what you suggest would be an extremely short-sighted "strategy" for a consultancy. Sure, you might get the next contract working this way. But once the customer could get rid of you they would, and they would never hire you again.

Then please answer why Elm was chosen instead of some mainstream programming language/framework. Choosing Elm seems like a very risky choice for something as important as railways.

Elm is a frontend language. Java works on the backend.

At Vy, Elm is used for frontend, Java and Kotlin for backend.

This doesn't address the issue of mainstream technology, versus bleeding-edge, obscure, niche technology such as Elm.

Kotlin in the backend isn't a mainstream technology choice either.

Elm was chosen because we believed it to be a better language than those which are mainstream right now. We believed it would make us more productive, prevent bugs before they reached production, be better at local reasoning and make it easier to onboard new people.

So far we are not dissapointed, and in my opinion Elm is on its way to become mainstream because of these things.

Rail ticket prices are decided at the government level in Norway, so this should have quite a minimal effect on those.

Also, as learning Elm is quite fast - I don't think the vendor lock-in is a very convincing argument.

Reply on news.ycombinator.com