5 ms·

It's a wise decision if you care about engineers being engaged and liking their job.

by iopq 11y ago

binwiederhier 11y ago
I've seen these types of projects where a few developers just went overboard with all the new frameworks and languages. Two years or so later most of them have moved on and other devs are stuck with technologies that are now considered outdated. Especially in the JS world, that's a real scenario. I am all for keeping your engineers happy. Heck I am one of them. "Exciting" can mean "better architecture" or "extensible", but I think that adding a new language is always a bad idea.
- marcosdumay 11y ago
  > other devs are stuck with technologies that are now considered outdated Isn't that a case of not letting developers rewrite anything? How did it got so outdated? Anyway, the Javascript world sucks. Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong.
  - frostmatthew 11y ago
    > Isn't that a case of not letting developers rewrite anything? How did it got so outdated? If you're writing (or rewriting) using whatever's hip/new there's a good chance it will be "outdated" within a few years. New languages and frameworks come out all the time and nobody is able to determine with certainty which have real staying power - but something that has been in [wide] use for 10+ years is much more likely to still be widely used ten years from now than something that just came out last year. Think of it like music, people have been listening to Mozart for centuries - it's highly likely a hundred years from now people will still enjoy his music. It's a lot less likely they'll be listening to Taylor Swift (nothing against her / her music - just using her as an example of someone who's very popular right now).
    - marcosdumay 11y ago
      There's also a chance writing your project on that 10+ years old platform will cost you enough time/money to write it three times in a more modern one. Well, you sound like somebody who I'd agree with most actual decisions about this. But I do disagree with the overall position. Holding down too much at "it works, don't change" has actually worse consequences than adopting immature frameworks all the time. That's not exactly like music - software tools do get old. Good platforms, of whatever age normally last for a long time and should be safe. But if for some chance one didn't last, one shouldn't be too resistant to replacing it (piecewise and slowly), because the cost of not doing that is just too big.
  - warfangle 11y ago
    > Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong. I don't think it's that they get outdated. It's that they each try to solve the hardest problem of web UI programming: keeping track of state and binding data in an asynchronous world. Unfortunately, each one ends up with pain points in different places. Each successive framework tries to solve the new pain points by rethinking the original problem, because reworking the original framework to ease that pain point would often require massive restructuring of apps built on that original framework - the issues are often architectural. Angular, for example, is fantastic for getting a very simple CRUD app up and working. But try to do anything fancier and things get very hairy very quickly with a web of controllers, directives, scopes, etc. Getting into a place where one data change cascades and kills your app is a very real concern. That's the pain point React/Flux attempts to solve. Angular can't solve it without some major architectural changes - see the hubbub about Angular2. We're still in the baby stage, I feel - while each successive framework may seem faddish, they don't really get outdated. Out of favor for new projects, perhaps, because the developers who used the older framework were so frustrated with the previous tool's rough edges. Things will probably settle down soon (especially with the fantastic language improvements in ES2015) :)
    - gaius 11y ago
      You know, if Microsoft developed all its other applications in VBA and ran them inside Word, they'd be a laughing stock. But everyone else in the world thinks it's sane to write applications inside a thing meant for displaying documents...
      - warfangle 11y ago
        Got a better solution, with wide adoption, that can get you on just about every internet-enabled consumer-facing computer in the world with the same codebase? :)
- mannykannot 11y ago
  Indeed, and it is not just with frameworks and languages, but also architectural and methodology fads. Several times, I have seen those who see themselves as architects try to roll their own frameworks or even languages within a project (the 'inner platform' phenomenon, which is quite common.) Those I have seen have all been failures, once catastrophically so. As a result of its effects on the work of other members of the team, such people often have a negative net productivity. I, too, am in favor of making things interesting where possible, but not to the point of indulging the Dunning-Kruger effect.
icegreentea 11y ago
Ha. I mean, every engineer loves a green field project, and everyone wants to do a technically sweet project. But engineers of all people should understand that not every project can be technically sweet, and certainly not every project can be greenfield. Could you imagine if everytime you wanted your HVAC upgraded, your contractor decides to rip out your entire current system and replace it with something new ("this new polymer ducting is awesome!") just to keep their engineers happy? There's a time and a place for all types of projects, and the mark of a successful engineering effort is to have engaged engineers regardless of the 'cool factor' of their work. In fact, this whole thing stinks of poor leadership (not just management) and undisciplined engineers.
- cam- 11y ago
  Engineers always under estimate the amount of business logic in an existing application. This is one reason my mainframe apps are so hard to replace, they often have 30 years of business logic built into them.
  - guncha 11y ago
    I agree with you on principle, but I've always wanted to see one of these "30 years of business logic" apps up close. What's most of that business logic? I can't imagine all of it being essential and at the minimum possible complexity.
    - Schwolop 11y ago
      "Normally, component A completes then sends a message to B, who blocks while a file operation occurs, and then sends a confirmation to C which updates the UI. When configuration option D is enabled, B must make the write twice because of X, which requires component E to act as a delegate to intercept the normal message from B to C so that this can occur without changing the implementation of C, since it has been externalised and is used in six other projects. Also, file writes are disabled on weekends, except the fourth weekend in February, unless this weekend doesn't occur." -- snippet from a more or less realistic set of requirements for a "2 years of business logic" app. I do not want to be here in another 28 years...
dham 11y ago
In the backend, a new language for a new service would likely be ok, if it's pretty small. If you chose any of the major frameworks for your application you'll be good. Django, Rails, Java EE, Spring, Play Framework, Meteor. These aren't likely to go away anytime soon, and they've been around for a while. On the front end it's a much more dangerous approach. If you have one or two pages that use the latest flavor of the month, Backbone(2011) Knockout(2012), Angular(2013), React(2015), you'll be ok. The problem comes when you just re write your entire front end app in one of these. I like to experiment with front end technologies on one page, but I would never buy into the SPA for the entire app. The shelf life is way to small. They'll still be supported probably. If your trying to keep or hire developers, putting backbone.js as a tech you use probably won't get as many applicants as say React.js. Since most front end devs right now are trying to introduce React into current job or jump to a job where they use it.
JustSomeNobody 11y ago
I've personally seen this cost a company millions of dollars and years without a next product.
nodamage 11y ago
If an engineer gets bored and leaves because they wanted to rewrite your codebase and you said no, that's probably not an engineer you wanted to retain anyway. Even if you said yes, you're only kicking the problem down the field a bit, because six months later they'll get just get bored of the new stuff they've rewritten and will want to move on to rewriting something else. Ad infinitum. I consider these people the "90% engineers", meaning they like to take a project from 0% to 90% complete, but then once the going gets tough, and they're no longer writing new code but trying to track down the bugs in their existing code, they decide it's no longer fun and need to move on to something else. These people usually fail to realize the implicit risks associated with throwing away an existing codebase and starting over from scratch. All that time spent ensuring the business logic is correct and tracking down obscure bugs will need to be repeated in their new rewrite. (Spolsky elaborates: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) These people are essentially spinning their (or rather, their company's) wheels by creating more work for themselves, without actually getting anything done.

It's a wise decision if you care about engineers being engaged and liking their job.

by iopq 11y ago

It's a wise decision if you care about engineers being engaged and liking their job.

I've seen these types of projects where a few developers just went overboard with all the new frameworks and languages. Two years or so later most of them have moved on and other devs are stuck with technologies that are now considered outdated. Especially in the JS world, that's a real scenario. I am all for keeping your engineers happy. Heck I am one of them. "Exciting" can mean "better architecture" or "extensible", but I think that adding a new language is always a bad idea.

marcosdumay 11y ago
> other devs are stuck with technologies that are now considered outdated Isn't that a case of not letting developers rewrite anything? How did it got so outdated? Anyway, the Javascript world sucks. Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong.
- frostmatthew 11y ago
  > Isn't that a case of not letting developers rewrite anything? How did it got so outdated? If you're writing (or rewriting) using whatever's hip/new there's a good chance it will be "outdated" within a few years. New languages and frameworks come out all the time and nobody is able to determine with certainty which have real staying power - but something that has been in [wide] use for 10+ years is much more likely to still be widely used ten years from now than something that just came out last year. Think of it like music, people have been listening to Mozart for centuries - it's highly likely a hundred years from now people will still enjoy his music. It's a lot less likely they'll be listening to Taylor Swift (nothing against her / her music - just using her as an example of someone who's very popular right now).
  - marcosdumay 11y ago
    There's also a chance writing your project on that 10+ years old platform will cost you enough time/money to write it three times in a more modern one. Well, you sound like somebody who I'd agree with most actual decisions about this. But I do disagree with the overall position. Holding down too much at "it works, don't change" has actually worse consequences than adopting immature frameworks all the time. That's not exactly like music - software tools do get old. Good platforms, of whatever age normally last for a long time and should be safe. But if for some chance one didn't last, one shouldn't be too resistant to replacing it (piecewise and slowly), because the cost of not doing that is just too big.
- warfangle 11y ago
  > Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong. I don't think it's that they get outdated. It's that they each try to solve the hardest problem of web UI programming: keeping track of state and binding data in an asynchronous world. Unfortunately, each one ends up with pain points in different places. Each successive framework tries to solve the new pain points by rethinking the original problem, because reworking the original framework to ease that pain point would often require massive restructuring of apps built on that original framework - the issues are often architectural. Angular, for example, is fantastic for getting a very simple CRUD app up and working. But try to do anything fancier and things get very hairy very quickly with a web of controllers, directives, scopes, etc. Getting into a place where one data change cascades and kills your app is a very real concern. That's the pain point React/Flux attempts to solve. Angular can't solve it without some major architectural changes - see the hubbub about Angular2. We're still in the baby stage, I feel - while each successive framework may seem faddish, they don't really get outdated. Out of favor for new projects, perhaps, because the developers who used the older framework were so frustrated with the previous tool's rough edges. Things will probably settle down soon (especially with the fantastic language improvements in ES2015) :)
  - gaius 11y ago
    You know, if Microsoft developed all its other applications in VBA and ran them inside Word, they'd be a laughing stock. But everyone else in the world thinks it's sane to write applications inside a thing meant for displaying documents...
    - warfangle 11y ago
      Got a better solution, with wide adoption, that can get you on just about every internet-enabled consumer-facing computer in the world with the same codebase? :)
mannykannot 11y ago
Indeed, and it is not just with frameworks and languages, but also architectural and methodology fads. Several times, I have seen those who see themselves as architects try to roll their own frameworks or even languages within a project (the 'inner platform' phenomenon, which is quite common.) Those I have seen have all been failures, once catastrophically so. As a result of its effects on the work of other members of the team, such people often have a negative net productivity. I, too, am in favor of making things interesting where possible, but not to the point of indulging the Dunning-Kruger effect.

icegreentea 11y ago

Ha. I mean, every engineer loves a green field project, and everyone wants to do a technically sweet project. But engineers of all people should understand that not every project can be technically sweet, and certainly not every project can be greenfield. Could you imagine if everytime you wanted your HVAC upgraded, your contractor decides to rip out your entire current system and replace it with something new ("this new polymer ducting is awesome!") just to keep their engineers happy? There's a time and a place for all types of projects, and the mark of a successful engineering effort is to have engaged engineers regardless of the 'cool factor' of their work. In fact, this whole thing stinks of poor leadership (not just management) and undisciplined engineers.

cam- 11y ago
Engineers always under estimate the amount of business logic in an existing application. This is one reason my mainframe apps are so hard to replace, they often have 30 years of business logic built into them.
- guncha 11y ago
  I agree with you on principle, but I've always wanted to see one of these "30 years of business logic" apps up close. What's most of that business logic? I can't imagine all of it being essential and at the minimum possible complexity.
  - Schwolop 11y ago
    "Normally, component A completes then sends a message to B, who blocks while a file operation occurs, and then sends a confirmation to C which updates the UI. When configuration option D is enabled, B must make the write twice because of X, which requires component E to act as a delegate to intercept the normal message from B to C so that this can occur without changing the implementation of C, since it has been externalised and is used in six other projects. Also, file writes are disabled on weekends, except the fourth weekend in February, unless this weekend doesn't occur." -- snippet from a more or less realistic set of requirements for a "2 years of business logic" app. I do not want to be here in another 28 years...

dham 11y ago

In the backend, a new language for a new service would likely be ok, if it's pretty small. If you chose any of the major frameworks for your application you'll be good. Django, Rails, Java EE, Spring, Play Framework, Meteor. These aren't likely to go away anytime soon, and they've been around for a while. On the front end it's a much more dangerous approach. If you have one or two pages that use the latest flavor of the month, Backbone(2011) Knockout(2012), Angular(2013), React(2015), you'll be ok. The problem comes when you just re write your entire front end app in one of these. I like to experiment with front end technologies on one page, but I would never buy into the SPA for the entire app. The shelf life is way to small. They'll still be supported probably. If your trying to keep or hire developers, putting backbone.js as a tech you use probably won't get as many applicants as say React.js. Since most front end devs right now are trying to introduce React into current job or jump to a job where they use it.

JustSomeNobody 11y ago

I've personally seen this cost a company millions of dollars and years without a next product.

nodamage 11y ago

If an engineer gets bored and leaves because they wanted to rewrite your codebase and you said no, that's probably not an engineer you wanted to retain anyway. Even if you said yes, you're only kicking the problem down the field a bit, because six months later they'll get just get bored of the new stuff they've rewritten and will want to move on to rewriting something else. Ad infinitum. I consider these people the "90% engineers", meaning they like to take a project from 0% to 90% complete, but then once the going gets tough, and they're no longer writing new code but trying to track down the bugs in their existing code, they decide it's no longer fun and need to move on to something else. These people usually fail to realize the implicit risks associated with throwing away an existing codebase and starting over from scratch. All that time spent ensuring the business logic is correct and tracking down obscure bugs will need to be repeated in their new rewrite. (Spolsky elaborates: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) These people are essentially spinning their (or rather, their company's) wheels by creating more work for themselves, without actually getting anything done.