3 ms·
>One great example of this is the debacle of the Amazon internal wiki migration. Back in 2015, the Amazon InfoSec team banned PHP at the company. Oof. To be fa
by vsareto 7y ago
>One great example of this is the debacle of the Amazon internal wiki migration. Back in 2015, the Amazon InfoSec team banned PHP at the company.
Oof. To be fair, Java is probably way easier to code review.
- Filligree 7y agoMuch depends on the Java. Having spent a lot of time on personal projects using the language, it doesn't deserve its reputation -- Java may 'require' an IDE to avoid spending too much time on boilerplate, but modern Java is a good language and the programming experience once you do have that IDE is one of the best, most effective I know. At the same time, it's absolutely possible for codebases to become "enterprisey" to the point where even the tiniest change takes weeks. Some of the libraries out there use absolutely horrifying patterns. If you're just coding for yourself, you can avoid those. In a company maybe not so much, and even though the company would be better off avoiding them, maybe they have old code remaining from when such things were considered good.
- The_Colonel 7y agoPeople really, really overrate the importance of a language. Java as a language is quite decent, but definitely not great. What makes it great is everything around it - from second to none JVM, range of state-of-the-art developer tools to the best library ecosystem.
- JackFr 7y agoI just had an coding interview where the interviewer was guiding me to create a class called “ResponseBuilderVisitorBuilder” Run away!!! (And I like Java!)
- jimbokun 7y agoAs long as you can avoid Spring, Java is a great development platform!
- AndrewUnmuted 7y agoI remember thinking that the internal wiki at anzn was one of it's best workplace features. This was something used by just about every team and rarely needed intervention from internal developers to operate smoothly. This was prior to the migration though. I can't imagine how much upheaval there was resulting from the migration, language considerations aside. This is probably one moment where tech concerns should have taken a back seat to company stability.
- vsareto 7y agoMuch of that depends on their justification. It's entirely possible it was made only for broad risk-avoiding reasons due to PHP's reputation at the time (anyone could have "safely" made that decision, you don't need infosec skills to make that call). They could have done a detailed inventory of what they use and found a bad history of bugs like multiple auth bypasses, trivial RCE. Or they might have audited a few of the products themselves and saw the code quality was typically poor and prone to security issues.