[rodh257]

Really interesting article, thanks for writing it. I'd like to hear a bit more about the reasoning for the whole company swap, what problems you were having with C#/Microsoft stack. The impression I got was that you tried out something new for a small project, liked it and liked the idea of OSS in general and then started doing everything in that way, is that all there was to it? What other factors came into the decision on a whole?

[300bps]

I found the article very interesting as well but honestly it reads like a nightmare.

Company heavily invested in X. New CTO comes on board, gives the technology stack a "hard look" which is often a euphemism of, "I wouldn't have chosen that technology, so you must change." Large portion of the existing developers leave, new developers (including OP) come in. New developers base technology decisions on what's best for their career, not necessarily what's in the best interests of the company.

After all, in the Why Scala section they plainly state they knew little of Scala and there's a large section about what languages are hiring.

And as you said, if there is time spent on what made them decide to switch away from the Microsoft stack, it is buried to the point I couldn't find it in two read-throughs of the very long article.

[andyjohnson0]

Thats how it read to me too. Except I translated the CTO's "hard look" as "what big thing can I change to show I'm in charge."

Irrespective of the merits of the technology [1], if hiring a new CTO results in a lot of the existing development staff leaving then something is very wrong.

[1] I work on the .net stack, but I've tried Scala and think its a great language.

[seglo]

I'm sorry this is how the article came across to you. Given similar sentiments from others on this thread I'll see if I can amend it to make it more clear.

When our CTO came onboard I meant to say that he gave a hard look at our development process, not so much the technology stack itself. I agree it's confusing since the post is about Technology Change and I'm probably confusing the point further by mentioning both the earlier process transition when our CTO came onboard and then the later Scala technology change.

Thanks for your feedback.

EDIT: I've updated my post to elaborate on why a new CTO was brought into the organization.

[MichaelGG]

Why not change dev methodologies while adopting F# to have a proper modern language? Seems like it'd make migration a far easier task, if you don't really need all of Scala's type system.

[seglo]

We weren't looking at FP languages specifically. We also were leaning toward something that could be run on Linux.

[pnathan]

I'm going to dump a few assertions -

.NET culture is not F/OSS culture. Different personalities and types of people in those camps. Different expectations of capability. When you are looking to hire non-Blub programmers, it's a lot easier to find it in F/OSS-land.

F/OSS tooling has a big priority on interop with each other. MS tooling has a big priority on interop with MS (and companies that MS has contracts with or has strategic EEE priorities on). Having a broader base of tools to use is a big deal.

F/OSS development progress can be monitored and input can be given (and patches can be sent in). This is in contrast to the proprietary approach where you pretty much have to take what you're given, and input is limited (depending on company). So it's easier to manage church and breakage risk in F/OSS.

Full-size enterprise MS licenses are not cheap. The numbers I've heard thrown around are big. And it seems that MS tooling is focused on vertical scaling, so your HW costs start looking very large as you stack your enterprise memory & HA storage systems into the box. This is opposed to "el cheapo" redundant pizzaboxes. So you start incurring a particular kind of expensive cost.

All of these are reasons I think F/OSS development is a better place to be, to hire from, and to want to go to. None of those reasons were given in the article, so we are left with speculation - was this just the CTO throwing his weight around? was this an attempt to move to a more mentally flexible organization? was this an attempt to cut costs?

[_random_]

"hire non-Blub programmers, it's a lot easier to find it in F/OSS-land" - I am not sure that's the case, everyone seems to be crazy about Python, Ruby and JS.

[jmagoon]

Can you elaborate on this? I'm a new developer and would be interested in this perspective. If they have a new, energized staff that is shipping software on time and have old, untouched software that still works and communicates with the new software, what is the problem with that?

Looks like many agree with you, so I'm really curious about what problems arise long-term from decisions like that.

I mean...our legacy code is in BASIC...but if they told me I needed to maintain the BASIC programs, I would probably quit.

[taude]

I don't see having some of the old-school developers leaving the company and being replaced by potentially better talent as a bad thing. One signal for me is that I hire smart people because technology changes. It's a red flag for me when people stop learning or lose the desire to add to their tool belt. Some people can't adapt.

But, hey, the world still needs Cobol programers, so...

[300bps]

old-school developer

With all due respect, you obviously know nothing about the Microsoft stack. These people were not using VB6. How do I know? From the article:

new projects chose a base technology stack of C#, ASP.NET MVC

ASP.NET MVC is not an "old-school" framework. It was first released in 2009!! That's four years newer than Ruby on Rails. It's ridiculously actively developed as well as being open source. It's currently in version 5 which was released October 17, 2013 which was... OMG 8 days ago.

I continue to be shocked at how little most HN developers know about the Microsoft stack and how much innovative work has been done since they last looked at it in 1998.

[taude]

Ha, I worked a lot with ASP.NET MVC 2 & 3! By old-school, I was referring more to the lockin of the MSFT stack than the specificity of a particular library.

(When we moved over to a Python-based solution, we ported from MVC 3/SqlLinq/MS SQL Sever stack)

EDIT: Oh, and were had a lot of good stuff going on using ServiceStack....loved that set of libraries.

[_random_]

"moved over to a Python-based solution"

My condolences...

[kenjackson]

Changing for change's sake is probably much worse than sticking with something that works.

Chasing shiny things is great if that's your goal. But if your goal is to build great product, then focusing on that should be the goal. There's still a lot of great product written in C, Obj-C, C++, and Lisp -- all rather "dull" languages compared to the shiny new stuff.

[CmonDev]

Also that sentence has a strong implication that new developers are smarter than the old ones. Just because they choose one technology over another. I am personally well aware of Scala features, yet I choose C#.

[RogerL]

Yes, I also read it as the other responders to you read it. Losing your staff, probably spending more on talent (you usually, not always, have to pay more to replace somebody), losing tons of institutional knowledge, basically having to rewrite everything from scratch (I find it interesting how on HN we simultaneously laud moving to CoolTech2000 and quote Joel on never rewriting existing software) switching development to something new that no one has experience with - well, those all have huge and long lasting costs.

Against that, we weren't given a reason for the change. Maybe he was being nice and not exposing how things were. I'm certainly aware of dysfunctional teams that really need everything fixed, and there is little to do but wield the ax and get it done. But it is a heck of a gamble. These "old timers" - perhaps they were cranking out pretty good code at a good rate, on a stable system they understood, on time and budget, and so on, and had somebody come in, tell them they aren't buzz word compliant, and enforce things on them that neither solve problems that they have nor really offers much of an advantage. Or, perhaps they were dinosaurs that took 3 months of arguments between 5 committees to decide whether to label a button "reply" or "send". I dunno.

I've seen it both ways. I had a programmer react to my use of python as "oh, that silly little language". Everything must be written in C and reinvented by him. Not a very useful attitude. OTOH, if I was to storm around and argue that our existing, well working c code should be converted to Scala for no particular reason, I'm being the unhelpful one.

tl;dr: I didn't see anything in the article that made me think the existing team was doing it 'wrong' to incur such risk and costs. I don't much care if they are successful - the risk stands out like a sore thumb. We eviscerate the bankers that bet the company for their quarterly bonus by pursuing high risk, high reward strategies, and say "cool" when somebody throws out their team, source code, and institutional knowledge in favor of a cool new language and buzzwordy development process.

[taude]

I don't think they rewrote everything, though, did they? I read it that they were building up new stuff in this manner and they they were trying to move over to a SOA-style architecture, which it sounded like they didn't have with some old stuff.

I highly doubt they're just throwing all their products away.

[Pxtl]

As a C# developer I always find the problem with C# is the lack of any Darwinean process in MS libs. In a platform with a stronger open-source community, libraries battle it out in the marketplace of ideas and users and generally the solid ones rise to the top.

In .NET, MS provides everything, and the OSS counterparts are second-fiddle to the blessed libs. This is a problem since it stifles the OSS community trying to compete with first-party product... and while MS has generally competent coders and products, sometimes they make mistakes that are agonizing pain-points... and the MS obsession with "no breaking changes" means that those pain-points will never be fixed.

No MS mistake is ever fixed. It is replaced with a new library with a whole new week-long learning-curve and its own foibles and mistakes, which will, in turn, never be fixed.

[andyjohnson0]

I'm a C# dev too and I agree with you on the lack of "Darwinean selection". Definitely a downside of working on the Microsoft stack. Some of the great innovations coming out of the FOSS community seem to take a long time to reach us.

On the other hand, we miss a lot of the churn caused by people chasing after the latest js library, which also seems to be a big preoccupation of the FOSS community. If you're building software that has to last for years then stability of the underlying platform and having fewer ways to do something can be an advantage.

[pnathan]

> On the other hand, we miss a lot of the churn caused by people chasing after the latest js library, which also seems to be a big preoccupation of the FOSS community. If you're building software that has to last for years then stability of the underlying platform and having fewer ways to do something can be an advantage.

Don't make me figure out how many database access approaches there are in stock .NET. :-)

More seriously, JS devs seem to have a thing for reinventing each others wheels - not just once, but tens of times (hyberbole). I really don't see that behavior in other communities by and large. The worst I've seen elsewhere is 3 similar Python libs

I dig appreciate the stability argument though. Which is why I'm a Common Lisp fan; its a standardized and mostly extensible language.

[_random_]

"Don't make me figure out how many database access approaches there are in stock .NET. :-)" - one high-level using Entity Framework, one low-level using ADO.NET. Non-stock options are plenty.

[jimmaswell]

I've heard this a lot but haven't experienced it. Could you give an example?

[Encosia]

I disagree with Pxtl overall, but there are some high profile examples like Microsoft's Entity Framework coming from way behind and eventually overshadowing established open source ORMs like NHibernate.

On the other hand, creating a new ASP.NET MVC project with the official Microsoft template that ships with Visual Studio automatically pulls in open source libraries/frameworks like jQuery, Bootstrap, and Json.NET, not Microsoft-reinvented versions of those things.

[jimmaswell]

I meant more specifically some of these "pain points" where undesirable behaviors stay in the library so changes won't break anything.

[Touche]

ASP MVC

[pdubs]

...is open source.

[itsboring]

I use ServiceStack under Mono as an alternative to Asp.net mvc and I love it.

[seglo]

I'm glad you enjoyed the post, thanks.

In the beginning there wasn't an initiative to migrate away from .NET. Management encouraged us to try new technologies all time and the BeetleJuice spike seemed to me like a good opportunity to try something new given its simplistic requirements.

From an organizational perspective, there was some discord about how expensive our Microsoft infrastructure was and how poorly it scaled. I won't blame Microsoft for all our scaling problems, as a lot of it had to do with our legacy architecture, but licensing fees were a legitimate concern. Management didn't have any clearly defined goals to move away from Microsoft, but when we started using Scala, Mongo, and other open source projects they took the opportunity to make the case for more migration of our infrastructure. This new direction was officially announced as part of our CTO's Technical Strategy message to the dev department (included in my post).