octernion

> I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.

fwiw i voted you up because i strongly believe in constructive discussion around these things. i don't think you should take that as a signal that folks support this position.

> I'm sorry, but saying that as long as your process isn't broken...

i'm merely saying that from several shops i've worked at, including instacart, with many 10k+ lines of code rails codebases, i've never seen problems like what you've described and it sounds pathological for that specific application/company.

again my (and many others') point is that rails is absolutely maintainable, even at massive scale, and even in a world with ever-changing requirements, hard deadlines, and very loosely-understanding clients, and that all that takes is doing rails the "right way" (a comprehensive test suite, reasonable architectural design), and that it is still massively productive.

"Otherwise: don't bother." is a pretty strong statement and i think in the distinct minority.

how much of your statement is driven by that one example? that seems like a broken process or a poorly designed system (orthogonal to rails) than anything else...

as a counterpoint, i work at instacart, where we have rails apps (we broke our application into "macroservices" several years ago) each around ~50-200k LOC which we have maintained for 5+ years while growing exponentially (customer base) and not exponentially (engineering headcount :)

i've talked to other companies that have done similar things.

where are you getting any of this from?

That's awesome -- wasn't aware that was the case (wasn't many moons ago :). Thanks for the heads up! But, we don't use Kafka internally so it's sadly a non-option still...

Unfortunately, most of these LR programs don't work in AWS (RDS) land, since they require PG plugins, and RDS LR only supports the built-in test decoder.

I wrote a similar program that uses LR to stream changes to AWS's Kinesis[1], using a mini library that parses the output of the default test decoder[2] as a result, in case anyone else is in RDS and has the same limitation.

[1] https://github.com/nickelser/pg_kinesis [2] https://github.com/nickelser/parselogical

i am not entirely sure what you mean by this -- sorry. i was not trying to be divisive and offer a personal perspective as an engineer. can you clarify please?

just saw this -- no worries, and thank you for your response. i think that is very reasonable and we are excited to go head-to-head with amazon on all fronts (delivery experience, quality of jobs offered, retail offerings/selection/etc).

thank you for context, and sorry if i sounded snippy in my response.

i was mainly noting the source for markups as we cannot tell you that delta -- it's up to the stores to tell us what they want to charge online. we do want to be as transparent as possible! ("possible" being the operative word here)

thank you for the kind feedback -- we love to hear from customers who we help like this! and, we are constantly trying to improve the experience (especially the replacement experience!)

as i have noted elsewhere in the thread, that is a message -- from the retailer -- that the prices are different from in-store (and again, online pricing is their prerogative).

instacart is not marking anything up.

edit: it seems clear that we can do better in terms of communicating this, so i've passed that feedback on to the team.

again, in 99.99% of the cases, we aren't doing the markup.

and, in the one case where we do not have a signed relationship with the retailer, we do explicitly note the percentage.

we aren't hiding anything. and, you have that precise problem with amazon prime -- what markup are they charging?

i am very confused why you have a higher bar for this than other services. would you actually create a spreadsheet that values your time (against other alternatives), gas/lyft/train fare to and back from the store, the extra costs associated with actually being in a retailer (and seeing the specials in store etc) and compare that against our offering?

and again, we aren't the ones doing the markup -- those are coming from the retailer directly, who may (or may not) mark up prices, which is their prerogative. we put all of our costs in the checkout screen transparently.

right now, whole foods is something like 1 or 2% of the grocery market in the US. we plan to be the partner to the rest of the nation -- my initial question was how on earth you can just assume amazon (by default) owns the rest of the high end market, and, why you think "bolting on delivery" is easy/trivial.

i know there has been a lot of changes with that recently -- i agree also that is odd. there are a ton of legal nuances here that i do not want to get into, but suffice to say we want to be clear and transparent to customers while at the same time providing a compelling wage to all the folks who touch your order during any part of the lifecycle.

groceries are unlike pretty much every other online segment, which is why it has resisted being moved online (until very recently). the model of having a warehouse simply "near" a city is a model amazon has tried for 10+ years without success -- you must have many warehouses within the city to make it work.

i am not entirely clear how you arrived at "Does instacart fit ? it seems not.", so it would be good to understand that. we have spent 5 years with hundreds of engineers building a fulfillment/logistics network just for groceries that any grocer can just leverage off the shelf.

i am not entirely sure what they mean by that. the service fee goes 100% towards the shopper fleet and is an essential part of a reasonable compensation structure for all of our shoppers -- if we switched entirely to tips, the folks that (e.g.) actually picked out your groceries, checked out & staged your groceries at the store, would not be compensated. this is because tips have to go 100% to one person, which would only be the delivery person -- and in our case, any one order is handled by many people to be efficient.

we used to provide specific percentages, but phased that out over time as it was obvious that wasn't providing real value -- where on amazon.com do you see their markup?

additionally, for virtually all stores on instacart.com now, we are simply passing on the pricing that the retailer has given us (which may or not be marked up from their internal prices -- but we do not control)

edit: to be crystal clear, that means that you are getting exactly what you are asking for -- the prices are simply what the retailer sets (which may be marked up from in-store -- that's their prerogative), and then we show our fees on top of that on checkout. we aren't "hiding" anything, and it's your decision whether the fees are worth your time.

as an engineer at instacart, it's very disheartening for me to see the top-rated comment on HN is "I can’t wait for instacart to go out of business."

even if we did not provide value to you (which i apologize for -- it is a priority of ours to improve the replacement experience in particular as it is very frustrating to customers), i am not sure why that implies that we do not provide a valuable service for others and why you would wish ill on us.

perhaps it is because you think of us as an overall unscrupulous company ("shady fees", "mark up everything you buy"), which i would contest -- we strive for transparency when possible (see [1] for screenshots around how we describe the pricing of our service). but the larger point remains -- why do you think that there can only be one victor here, and that is has to be amazon? (or "amazing" as you put it).

right now, amazon is very explicitly coming for the grocery industry -- an $800+ billion industry that is almost 100% offline -- and we are attempting to be one of the (hopefully many) independent companies that enables it online. grocery companies have built amazing fulfillment pipelines and relationships with both farms & customers that we are building a front-end and logistics system for.

anyways, i do not speak for instacart as a company, just for myself as an employee who usually enjoys HN.

[1] https://imgur.com/a/j47ls

as an instacart engineer, i'd be super curious as well. i haven't seen many actual data-driven cases (noting this honestly and thank you for acknowledging the attitude in your initial comment :)

Those are not "fake quotes" -- they are directly in the parent I was replying to...

I am not sure you can matter-of-fact state that "Precisely the opposite is true"; this is in fact, not true.

I am not going to respond further as it's not entirely clear where you are getting any of your information ("layered-over-retail model carries all the overhead of retail and then some" as an example of a totally unsubstantiated and untrue statement).

Yep, makes sense -- take my comment as "how things stand now" not "everything is hunky-dory" -- we will definitely be looking at this.

since then, we've formally partnered with Costco and have adopted their online pricing model (still more expensive than the store, but not by very much): http://www.sfgate.com/business/article/Costco-debuts-new-gro...

  there is no Ralfs [sic] API to plug into to give real-time inventory information

[citation needed] :) there are many ways to "vertically integrate" with retailers (and yes, some do in fact offer a real-time API of what is in store, and our availability information for those is fantastic)

I was noting our model in comparison to Amazon, which has it's own set of inefficiencies -- capital for warehouses far outside of city boundaries, the dedicated labor force/trucks, spoilage and selection issues, etc.

In no way am I noting that our model is perfect or without inefficiencies, just that the idea that "Amazon has the perfect and most efficient grocery delivery system" and "to attempt to use local retail grocery stores as a collective warehouse is not profitable" is just a fallacy.

I’m not sure what this means. The OP was frustrated with something they thought we were doing, and I (as the engineer who wrote the actual code and knows what we do and do not talk about) wanted to set the record straight.

We do use (as inputs) problems folks report with replacements (which include “too expensive” as an option), so theoretically this is covered, but I do think that we will be looking at the initial ranking and boosting as it seems this is a consistent problem. As I noted elsewhere, we will be looking at better collecting preferences from customers as “the majority of customers” approaches don’t always work for very personal items like groceries (eg some folks would prefer to have it organic regardless of cost!)

Can you clarify what you mean by "prices are consistently reasonable"? We do try to publish precisely what business model we are operating with pretty prominently on our storefront (e.g., if we have price parity with the store, or have a markup).

(engineer @ Instacart)

I'm glad you are having a positive experience -- it's really heartening to see feedback like this.

(engineer @ Instacart)

Please contact our support team in these cases, we absolutely aren't deliberately choosing more expensive items in order to profit -- see my comment elsewhere on this article, but we primarily look at your previous preferences and the preferences of other customers.

If you chose the cheapest possible option, it does seem inevitable that any replacement would be more expensive :-)

And, sorry that we were frustrating to you.

(engineer @ Instacart)

We actually take a lot of pride in our front end (most recently, to make as accessible as possible). Can you be more specific?

(Engineer @ Instacart)