4 ms·

Last time I had a phone screening with the, I learned their entire codebase was in Perl, with no plans on migration to anything else. There were almost no unit

Last time I had a phone screening with the, I learned their entire codebase was in Perl, with no plans on migration to anything else. There were almost no unit tests anywhere. Most developers could push directly to production. Everything the girl on the phone said was horrifying and I decided not to continue. Their recruiter kept trying to call me over Skype though, and they offer more than most other companies of that size in the EU, so I suspect they're pretty desperate. This was back in 2015 so maybe it's changed, but it sounds like a terrible place as far as technology and tech debt goes.

kbenson 7y ago
> their entire codebase was in Perl, with no plans on migration to anything else. There were almost no unit tests anywhere. Most developers could push directly to production. One of these things is not like the others. Not liking Perl is a valid personal choice, but doesn't say much about the codebase. The others are telling though. More so if it's true given that Perl has a very heavy culture of testing (the TAP protocol comes from Perl, and Perl is known for being very test heavy in its module ecossytem), which means they would be going against that culture to have no unit tests. That said, I'm not sure if we should consider "the girl on the phone" doing the screening as knowledgeable about the process. That description doesn't convey that you thought very highly of her, so I'm not sure why we should take her word as authoritative...
- riffraff 7y ago
  The third hand knowledge I have of booking.com was that lack of unit tests was an explicit choice. I.e. they felt it was more efficient to just catch bugs in production and be quick to fix them than spend time in unit tests that got obsolete fast and add friction. I didn't buy in the narrative, but it was an interesting perspective.
  - kbenson 7y ago
    I agree, that sounds like management being afraid to deal with the technical debt they've accrued.
gherkinnn 7y ago
You’re not the first to mention Bookings lack of tests. Supposedly it’s because their code has a very short half-life, gets rewritten in no time and thus tests are seen as a hindrance. Not that I agree, but it’s what I’ve heard.
- winrid 7y ago
  I'd say that's a better reason to write tests :)
lizmat 7y ago
One should understand that at Booking, the only thing that counts is "conversion". In other words, the ability of converting a pageview into a reservation. Because that's the part of the process that creates value. Since hotel reservations refer to a real world, where people change their plans, hotels get overbooked, burn down, are not reachable because of strikes, volcano eruptions, etc. etc. there is a huge customer service department. These people are able to cancel reservations, or force availability (after consultation with the hotel). In other words, until people have stayed at the hotel, and the hotel gets the bill for that, it really does not matter whether something was correct or not: the customer department can fix any problems. So the only valid test is really: does it convert? And this is very closely monitored in close to real time. The financial part of the system is thoroughly tested, as Booking.com is a listed company, so the scrutiny is extra severe. > Most developers could push directly to production. This is facilitates ownership and empowerment. You need to be sure that what you're doing, will not break things. If you are, it should be ok to push to production. If you were wrong, then that's ok the first time. Just don't do it again for the same reason: always make new mistakes! This was the situation in early 2012, when I basically retired. Things have changed since then, but I still think the above is still basically true.
mcv 7y ago
My brother loves Perl, so when he was looking for a job, I recommended Booking. I don't think he ever even applied for a job there, though. Possibly because of all the dark patterns.

kbenson 7y ago

> their entire codebase was in Perl, with no plans on migration to anything else. There were almost no unit tests anywhere. Most developers could push directly to production. One of these things is not like the others. Not liking Perl is a valid personal choice, but doesn't say much about the codebase. The others are telling though. More so if it's true given that Perl has a very heavy culture of testing (the TAP protocol comes from Perl, and Perl is known for being very test heavy in its module ecossytem), which means they would be going against that culture to have no unit tests. That said, I'm not sure if we should consider "the girl on the phone" doing the screening as knowledgeable about the process. That description doesn't convey that you thought very highly of her, so I'm not sure why we should take her word as authoritative...

riffraff 7y ago
The third hand knowledge I have of booking.com was that lack of unit tests was an explicit choice. I.e. they felt it was more efficient to just catch bugs in production and be quick to fix them than spend time in unit tests that got obsolete fast and add friction. I didn't buy in the narrative, but it was an interesting perspective.
- kbenson 7y ago
  I agree, that sounds like management being afraid to deal with the technical debt they've accrued.

gherkinnn 7y ago

You’re not the first to mention Bookings lack of tests. Supposedly it’s because their code has a very short half-life, gets rewritten in no time and thus tests are seen as a hindrance. Not that I agree, but it’s what I’ve heard.

winrid 7y ago
I'd say that's a better reason to write tests :)

lizmat 7y ago

One should understand that at Booking, the only thing that counts is "conversion". In other words, the ability of converting a pageview into a reservation. Because that's the part of the process that creates value. Since hotel reservations refer to a real world, where people change their plans, hotels get overbooked, burn down, are not reachable because of strikes, volcano eruptions, etc. etc. there is a huge customer service department. These people are able to cancel reservations, or force availability (after consultation with the hotel). In other words, until people have stayed at the hotel, and the hotel gets the bill for that, it really does not matter whether something was correct or not: the customer department can fix any problems. So the only valid test is really: does it convert? And this is very closely monitored in close to real time. The financial part of the system is thoroughly tested, as Booking.com is a listed company, so the scrutiny is extra severe. > Most developers could push directly to production. This is facilitates ownership and empowerment. You need to be sure that what you're doing, will not break things. If you are, it should be ok to push to production. If you were wrong, then that's ok the first time. Just don't do it again for the same reason: always make new mistakes! This was the situation in early 2012, when I basically retired. Things have changed since then, but I still think the above is still basically true.

mcv 7y ago

My brother loves Perl, so when he was looking for a job, I recommended Booking. I don't think he ever even applied for a job there, though. Possibly because of all the dark patterns.