5 ms·

And how bad would it be if it wasn't so successful? Apple gets to point fingers at Microsoft for not being able to keep up if things go south.

pyre 15y ago
That would only matter if Apple was having infrastructure problems. If people just didn't want the product, those claims wouldn't make sense.
- varikin 15y ago
  From a logical standpoint, you are correct. From a marketing or political (business, no government politics), Apple could blame Microsoft for iCloud failing, regardless of the truth, to a point. To put it another way, I frequently tell people "Businesses choose Java because if it fails, it isn't because they choose Java." This means that if the Director of IT says to build with the industry standard of Java (or .Net), it is not the Directors fault if/when the project fails. The project manager, the developers, QA, middle management, etc failed to do it correctly. It is a safe choice since it is industry standard and thus well proven. If it takes longer and costs more, it means it was a much more difficult problem then they expected, but since they used Java they got it working. If on the other hand, they went with Rails/Django/Node.js/Erlang/NoSQL/etc, and it fails, the Director chose to use "new and untested" technologies, he/she is the root cause. Regardless of the fact that it could just be that realistic goals/management were never used. I am not trying to say Azure is industry standard or the safe choice, but the way to shift blame is the same.
  - felipemnoa 15y ago
    Considering the amount of none trivial work about having to port your apps from one Rails version to the next I would be surprised if the Director didn't get part or most of the blame for forcing them to use Rails. And saying that they could just stay in an old version is not valid. When bugs are discovered in the old version most likely they will not be fixed because everybody has already moved on. Enterprise projects already have a high rate of failure and building it on a platform that has a history of making substantial changes on every new version is a really, really bad idea. An honest risk analysis of the enterprise project would raise a huge red flag for using a technology that continues to change substantially in every version such that it is not backwards compatible.
    - varikin 15y ago
      And it was non-trivial to go from Java 1.4 to 1.5.
      - felipemnoa 15y ago
        With all due respect, I don't know what you are talking about. Programs in 1.4 run fine in 1.5. Every time there is a new version of Java I install it in my machine and just continue working as usual. I would be really upset if I had to spend time trying to make everything work again with every new version. They deprecate methods and functionality but they do not remove it. Java is not that much older than Ruby/Rails and it is pretty stable. Ruby/Rails may be great but I really don't want to go through the pain of having to port my code to the next version. I rather spend my time on adding new features. Even Android, which is many times younger, never does this. Everything is always backwards compatible. Android developers would be up in arms if they just decided to break all apps in a new version of Android. Granted, it could still happen because nobody is perfect. Although it has never happened in any of my apps and I don't know if it has ever happened at all except for the early Beta period. When something is no longer supported they deprecate the functionality but do not remove it.
        speleding 15y ago
        > Java is not that much older than Ruby/Rails According to wikipedia: Java = 1995, Ruby on Rails = 2004
        varikin 15y ago
        1.5 did introduce at least one major backwards incompatible change. A new keyword which meant any variables named enum now broke the app. Installing a new Java version on your desktop to run some app is different than rolling out a new major version of JVM/language for an enterprise application. There is a lot that went into ensuring everything still worked, including all dependencies, and that performance was acceptable. Maybe heap options needed to be changed because of how GC changed.
        15y ago

pyre 15y ago

That would only matter if Apple was having infrastructure problems. If people just didn't want the product, those claims wouldn't make sense.

varikin 15y ago
From a logical standpoint, you are correct. From a marketing or political (business, no government politics), Apple could blame Microsoft for iCloud failing, regardless of the truth, to a point. To put it another way, I frequently tell people "Businesses choose Java because if it fails, it isn't because they choose Java." This means that if the Director of IT says to build with the industry standard of Java (or .Net), it is not the Directors fault if/when the project fails. The project manager, the developers, QA, middle management, etc failed to do it correctly. It is a safe choice since it is industry standard and thus well proven. If it takes longer and costs more, it means it was a much more difficult problem then they expected, but since they used Java they got it working. If on the other hand, they went with Rails/Django/Node.js/Erlang/NoSQL/etc, and it fails, the Director chose to use "new and untested" technologies, he/she is the root cause. Regardless of the fact that it could just be that realistic goals/management were never used. I am not trying to say Azure is industry standard or the safe choice, but the way to shift blame is the same.
- felipemnoa 15y ago
  Considering the amount of none trivial work about having to port your apps from one Rails version to the next I would be surprised if the Director didn't get part or most of the blame for forcing them to use Rails. And saying that they could just stay in an old version is not valid. When bugs are discovered in the old version most likely they will not be fixed because everybody has already moved on. Enterprise projects already have a high rate of failure and building it on a platform that has a history of making substantial changes on every new version is a really, really bad idea. An honest risk analysis of the enterprise project would raise a huge red flag for using a technology that continues to change substantially in every version such that it is not backwards compatible.
  - varikin 15y ago
    And it was non-trivial to go from Java 1.4 to 1.5.
    - felipemnoa 15y ago
      With all due respect, I don't know what you are talking about. Programs in 1.4 run fine in 1.5. Every time there is a new version of Java I install it in my machine and just continue working as usual. I would be really upset if I had to spend time trying to make everything work again with every new version. They deprecate methods and functionality but they do not remove it. Java is not that much older than Ruby/Rails and it is pretty stable. Ruby/Rails may be great but I really don't want to go through the pain of having to port my code to the next version. I rather spend my time on adding new features. Even Android, which is many times younger, never does this. Everything is always backwards compatible. Android developers would be up in arms if they just decided to break all apps in a new version of Android. Granted, it could still happen because nobody is perfect. Although it has never happened in any of my apps and I don't know if it has ever happened at all except for the early Beta period. When something is no longer supported they deprecate the functionality but do not remove it.
      - speleding 15y ago
        > Java is not that much older than Ruby/Rails According to wikipedia: Java = 1995, Ruby on Rails = 2004
      - varikin 15y ago
        1.5 did introduce at least one major backwards incompatible change. A new keyword which meant any variables named enum now broke the app. Installing a new Java version on your desktop to run some app is different than rolling out a new major version of JVM/language for an enterprise application. There is a lot that went into ensuring everything still worked, including all dependencies, and that performance was acceptable. Maybe heap options needed to be changed because of how GC changed.
        15y ago