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