Comment by sublinear
1 day ago
I'm pretty damn sure those videos were put on the page because someone in marketing wanted them. I'm pretty sure then QA complained the videos loaded too slowly, so the preloading was added. Then, the upper management responsible for the mess shrugged their shoulders and let it ship.
You're not insightful for noticing a website is dog slow or that there is a ton of data being served (almost none of which is actually the code). Please stop blaming the devs. You're laundering blame. Almost no detail of a web site or app is ever up to the devs alone.
From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.
> Please stop blaming the devs. You're laundering blame. Almost no detail of a web site or app is ever up to the devs alone.
If a bridge engineer is asked to build a bridge that would collapse under its own weight, they will refuse. Why should it be different for software engineers?
Because software engineers aren't real engineers. A real engineer has liability insurance.
Because bridge engineers can be sued if the bridge kills people
I wish we could sue developers who create unusably bad software wasting time of millions of people.
It's a website and not a bridge. Based on the description given, it's not a critical website either. If it was, the requirements would have specified it must be built differently.
You're not even arguing with me BTW. You're arguing against the entire premise of running a business. Priorities are not going to necessarily be what you value most.
> If it was, the requirements would have specified it must be built differently.
I’ve seen a lot of times where “business people” ask for a feature that sounds good but isn’t technically viable for any number of reasons. The devs not doing pushback would lead to similarly non-functional/broken stuff getting shipped.
The pushback doesn’t even need to be adversarial, just do some requirements engineering, figure out what they want and go “Okay, to implement X in the best possible way, we should do Y and avoid Z because of W.”
In the bridge analogy, the people who are asking for a specific design might not know that it’d collapse under its own weight and the engineers should look for the best solution.
There are environments where devs can't do that sort of requirements engineering and those are generally pretty dysfunctional - obviously you don't need that for every feature request, but it's nice to have that ability be available when needed.
While I assume that there are plenty of critical websites out there which are built with efficiency and resource consumption control in mind, the few I have worked on were not.
On those sites you’re right: the approach was different, but not necessarily better. Tracking library bloat and marketing-driven design were reduced. But insane “security” constraints (e.g. “you have to stay on outdated revisions of this library” or “containers are not allowed on the backend, only bare metal”, no joke—constraints that led to significant increased security risk) and extremely user-hostile design practices increased, as well as there being an exceedingly long hurry-up-and-wait turnaround time for shipping important fixes/improvements.
Working on a safety/state-critical site isn’t a panacea, in other words.
this isn't purely laundering blame. it is frustrating for the infrastructure/operations side is that the dev teams routinely kick the can down to them instead of documenting the performance/reliability weak points. in this case, when someone complains about the performance of the site, both dev and qa should have documented artifacts that explain this potential. as an infrastructure and reliability person, i am happy to support this effort with my own analysis. i am less inclined to support the dev team that just says, "hey, i delivered what they asked for, it's up to you to make it functional."
> From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.
this belittles the intelligence of the dev team. they should know better. it's like validating saying "i really thought i could pour vodka in the fuel tank of this porsche and everything would function correctly. must be porsche's fault."
Yes, but can you blame someone for trying when all the gas stations are 1000 miles away? That's the exact situation the devs are put in all the time.
Oh, and the rest of the business doesn't even know what a car or gasoline are!
this still undersells the developers' intelligence and presses the metaphor a bit too far. if the implication is that the developers are unaware of (or do not have access to) infrastructure capabilities, that's seems like a procedural failure (communication, education, information, etc). i wouldnt expect developers to know everything, but i'd expect them to be curious about how their work will interact with the goal, at large.
"Developers" here clearly refers to the entire organization responsible. The internal politics of the foo.com providers are not relevant to Foo users.
I agree except for your definition of "developers". I see this all the time and can't understand why the blame can't just be the business as a whole instead of singling out "developers". In fact, the only time I ever hear "developers" used that way it's a gamer without a job saying it.
The blame clearly lies with the contradictory requirements provided by the broader business too divorced from implementation details to know they're asking for something dumb. Developers do not decide those.
And the devs are responsible for finding a good technical solution under these constraints. If they can't, for communicating their constraints to the rest of the team so a better tradeoff can be found.
Fuck that. I just left a job where the IT dept just said "yes and" to the executives for 30 years. It was the most fucked environment I've ever seen, and that's saying a lot coming from the MSP space. Professionals get hired to do these things so they can say "No, that's a terrible idea" when people with no knowledge of the domain make requests. Your attitude is super toxic.
I suppose the realities of teamwork can be seen as "toxic" by some individuals.
I suppose I understand why devs who don’t know how to say no, or work with stakeholders, are terrified of AI. What value do you have, at this point, when you’re unwilling to or incapable of pushing back on bad ideas?
2 replies →
Sounds just like a "helpless" dev that shifts blame to anyone but themselves.
Do you have a suggestion how else to handle the situation I described?
There’s a magic word that can be used in scenarios like this: “No.”
Failing that, interpret the requirements.
Nobody can watch a bunch of videos at once that don’t even show up until you scroll! That’s a nonsense requirement and the dev’s failure to push back or redirect in a more viable direction is a sign of their incompetence, not that of the non-technical manager that saw YouTube’s interface and assumes that that’s normal and doable.
It is! You’d have to know about lazy loading and CDNs, but neither is black magic.
5 replies →
Man, I probably say no to like 40% of the requests I get as a dev. Often we will come up with a better way of doing things by just spending 15-30 mins talking to the business about the actual problem they are having.
Some are just flat out refused as they are just too stupid and will cripple the system in some way.
The devs are the subject matter experts. Does marketing understand the consequences of preloading all those videos? Does upper management? Unlikely. It’s the experts’ job to educate them. That’s part of the job as much as writing code is.
In general, how people communicate internally and with the public is important.
https://en.wikipedia.org/wiki/Conway's_law
Have a wonderful day =3
From the perspective of the devs, they have a responsibility for saying something literally wont fly anywhere, ever, saying the business is responsible for every bad decision is a complete abrogation of your responsibilities.
Why don't you tell your boss or team something like that and see how well that flies.
The responsibility of the devs is to deliver what was asked. They can and probably do make notes of the results. So does QA. So do the other stakeholders. On their respective teams they get the same BS from everyone who isn't pleased with the outcome.
Ultimately things are on a deadline and the devs must meet requirements where the priority is not performance. It says nothing about their ability to write performant code. It says nothing about whether that performant code is even possible in a browser while meeting the approval of the dozens of people with their own agendas. It says everything about where you work.
Maybe everyone’s got a different situation, but when a different department tried to put ActiveX avatars all over their site, though it offended me from a UX perspective, I was able to get higher ups to reject it by pointing out that it would shut out 20% of their customers.
We always have discussions here about how you have to learn to talk to communicate your value to clients in a language they understand. Same goes for internal communications.
> The responsibility of the devs is to deliver what was asked.
Software development isn't factory work. And factory workers are expected to notice problems and escalate them.
Anyway, they're paying me far too much to have me turn off my brain and just check the boxes they want checked in all situations. Sometimes, checking boxes because they need to be checked is the thing to do, but usually it's not.
1 reply →
I didn't say anything about their development abilities, what I am pointing to is their professional responsibility. If a doctor is asked by a client to cut off their arm and they say no, and the client fires them, did the doctor err? (No) This doesn't comment on their ability to do surgery.
2 replies →