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