Hacker News Reader

Comment by arscan | Hacker News Reader

I'm not so sure that it was node.js that revolutionized paypal... seems like the gains were from switching to a more agile process (and adding some supporting tools). A lot of the fixes seem pretty agnostic to the actual platform that they switched to.

Note that all those open source modules that they talk about aren't released yet. krakenjs.com doesn't even resolve (for me at least).

View on HN

Its will be a little saying too much, to say node.js revolutionized paypal. But speaking as a matter of fact programming languages do play significant role in the overall productivity of the teams.

I wouldn't be too surprised if they are saying using Java was making it difficult to turnaround issues. The problem isn't Java the language itself, but the processes involved in taking changes to production with these languages are generally so much ceremony large turnaround times become the norm.

Add to this issues like fixing build failures, test failures, code reviews that span meta aspects of code(config changes, xmls etc), running around to get libraries standardized per your company standards(getting it into your local maven repo etc); and much more. These sort of things really slow you down. With these if you are tending to multiples issues, or if you have dependencies on your colleagues- I wouldn't be surprised with the 6-month delays mentioned in the article are actually true.

Better said, since there is no compilation step, so you can push non working js through and it will look "green".

Java isn't defined by a process, that's sad most people don't seem to understand that. Look at projects like dropwizard, happily throwing away what they dont like.

I think you are close to the mark. There are ways to work in Java/JSP environment that is pretty quick cycle time. But I will say that our experience at PayPal is the code is more terse, less files, npm so much better than maven for managing dependencies, coupled with the fact that our javascript templating allows portability between server & client.

The Shift-Refresh style of programming is hard to overstate how much that creates a different mindset.

And to my point in the talk, the blending of prototyping and production tech stacks is also huge for being able to quickly iterate with users.

I think it was Stripe that got a fire underneath them.

Braintree and Square, too. Maybe more so than Stripe.

There is some brief lip-service paid to using the same language on the front-end and the back-end, but mostly you're right - they fixed processes, not technologies.

I can assure you that I had to attack multiple fronts. Process is a big part of it (I brought in LeanUX methodology), but I can tell you (and painfully so) that if we had not changed the technology we would not be moving at anywhere near the speed we can now.

Mind you that what you see on the PayPal sites is not all updated. This is a testament to just how deep the technical stack has been.

Other colleagues have been attacking the services layer and they are doing just as much change in that layer as my team has done on the app/frontend layer.

a new programming language is a perfect excuse to drop old ways of doing things, that way there's no legacy code pulling you back into old ways of doing things.

Unfortunately in practice that's not always the case. People are often so set in their ways they'll still try to do direct ports of "the old ways" even if the new language/platform offer easier/more elegant solutions. It can be very frustrating.

You raise a great point. Another big challenge we have had is re-educating developers. This has been helped by finding the really sharp engineers internally and hiring new engineers that bring in the right DNA.

I think we are getting to a tipping point, but it is a lot of work obviously.

Technology is not a silver bullet. Nor process. At the end of the day it is about your people. Technology & process can set them free.

I am doing a similar thing in a organization that has been at least as dis-functional, I know exactly what you're talking about. In fact, everything that you have presented and chatted about here resonates so well with me that I'd be interested in getting in touch with you. Case studies like yours are preciously rare on HN. My address is in my profile if you're open for it.

will ping you.

That's seriously going to reduce adoption of their open source modules. They're getting a lot of hits from this PR-piece, it's too bad they can't use any of that momentum for kraken or lusca...

and if you look at the http headers, every single one is apache, or apache tomcat.. ( when not akamai ). where they really using node.js?

Reply on news.ycombinator.com