bcarroll22

got it, thanks.

so based on this context and some other comments, it seems like the potential crime isn't so much that they use these sources to algorithmically suggest a price or contrived vacancy, it's that their agreement enforces that any of their subscribers has to use their suggestions on price and availability, thus making it likely price fixing. correct?

genuine question here, apologies if i missed it in the article, but what's RealPage's crime in this? how is using an algorithm to set prices on apartments more criminal than using an algorithm for anything else we use algorithms for?

i'm not saying it's not criminal, i just don't think i understand what american laws they're breaking by doing this.

> Hiring for a particular tool-chain or framework

Anecdata, but it wasn't helpful for my company to remove this boundary. I bought into the idea based on some other articles and threads posted here recently, but when we actually widened searches and removed the requirements from the postings, it didn't really move the needle.

I'm sure there's a group out there who isn't married to one stack, or is interested in learning a new one, but it was tough for me to feel like it was worth the added complexity of effectively screening and interviewing to accommodate it.

Is the suggested approach to focus sourcing on certain stacks but be open to interviewing promising applicants who don't use them? I suppose I could see that if your technical interviews can accommodate it without much rework.

I can dig this.

That said, if a mechanic says “if you don’t get this repair your tailpipe is gonna fall off” and you say “nah let’s risk it”, you’re not gonna go back to him when it falls off and say “wow I can’t believe you let me drive my car until the tailpipe fell off, you should’ve done better!”

If, however, a dev team says “hey guys, if we don’t fix this tech debt we’re gonna run into some perf issues and the site may crash” it’s a lot more likely they’ll come back and still find a way to blame the dev team when the product inevitably does crash or really struggle to deliver results.

Again, like my other comments say, this could be completely anecdotal on my part and totally greener grass thinking on my part, but it definitely does feel like this is the way the product teams I’ve worked with behave toward development teams.

I gotcha. I guess the confusion from my end is that I’ve yet to have a software development job where I wasn’t developing a product. No one in the orgs I’ve been a part of refer to the “product” team as the “product development” team. It’s just the product team, and the development team.

If that’s not been your experience then maybe you fall outside the target demographic of this article? I say that because it was super clear to me exactly what the author was talking about (in fact it even resonated with other members of my scrum team).

Alternatively, I suppose my experience could be anecdotal and not what most development teams encounter daily and struggle with.

"us" = development team "them" = stakeholders/product owner/project managers/managers/ux designers/etc.

this isn't the point of the article which is, in my opinion, a very good narrative of what its like to try to practice agile development in an organization with not very agile tendencies.

it was just a way to demonstrate that this kind of request at least _can_ be made to a restaurant staff and you don't think "wow they're totally gonna blow it" but you'd rarely, if ever, see a product team make a similar request to a development team.

great job to the author of this post for capturing this.

I echo this as well. Would be very nice to have Crashlytics for web.

> Research the concept of "Death Prices".

Google doesn't come up with anything on this one, is there a different term for the same thing?

Channing, thanks for sharing this. I hope it’s an inspiration for some other entrepreneurs out there!