I have a 2009 Citroen and the battery is secured with a bolt that is under the battery compartment and to access it you need to go under the car with a very long wrench, who engineered it is a psycho
I had a 2004 Citroen, which needed the front sidelight bulb replacing, after investigating for 20 minutes, decided to ask the garage how much it would cost next time it was in.
I left my Citroen to my mom, and my stepfather has calculated that a light bulb costs 3€, having the light bulb mounted by the mechanic costs 5€ ( including the bulb ), so to save up 2€ he decided ( with good cause ) that he will never replace the bulb himself cause it's extremely infuriating.
I did manage to replace those bulbs myself, and it's ridiculous, it has some sort of spring to hold it in place that is extremely hard to open with your fingers, and even harder to close. And on top of that you can't even see it, you have to take first pictures with your phone, understand how it works and then go entirely by tactic feedback
Since Dante wrote _The Inferno_, there has been a circle in Hell added where car designers are endlessly changing the spark plugs on AMC Javelins, bleeding brakes on Ford Escorts, and similar maintenance tasks which the design made more difficult than is reasonable.
Define "modern". I have a 2017 Civic and I've had to replace the battery a couple of times. There's a holding bar that needs to be removed before the battery can be taken out, but other than that the only real problem is the weight of the thing.
In general it looks like these kinds of changes are trying to make it harder for people to do this kind of basic maintenance themselves. Force you to go to the dealer.
I recommend to never go to the dealer, unless you're going there for a warranty or recall repair. A local repair shop is always the better option. And if you don't know of a trustworthy local shop, take it to the dealer for an estimate, and then you know if the local shops are bullshitting you (they should come in way under dealer prices).
Repair shop owners also don't enjoy work which is unnecessarily difficult.
Between rebuilding an engine and disassembling a bumper to replace a lightbulb most mechanics would genuinely rather be doing the lengthy but interesting work of rebuilding an engine than the lengthy and fucking boring task of disassembling a bumper to fix a lightbulb.
Moreover, even if a mechanic must charge you stupid amounts of labour cost to do a simple repair because it genuinely takes that much time, the customer might not come away with it thinking: "fuck, I bought a dumb car which is expensive to repair", they might instead come away with it thinking: "all these mechanics, quoting ridiculous prices to fix a light bulb, they must all be scammers".
Between rebuilding an engine and disassembling a bumper to replace a lightbulb most mechanics would genuinely rather be doing the lengthy but interesting work of rebuilding an engine than the lengthy and fucking boring task of disassembling a bumper to fix a lightbulb.
ChatGPT, write me a 2010-style Hacker News front page essay about how software maintenance is just like automobile maintenance, and why nobody wants low-value maintenance work to be arduous, failure-prone, and boring.
What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...
Right but what I'm getting at is that there can be tradeoffs that might make designing for maintainability mean optimizing for something less important to the end user.
Do you optimize an engine for how easy it is to replace a filter once or twice a year (most likely done by someone the average car-owner is already paying to change their oil for them), or do you optimize it for getting better gas mileage over every single mile the car is driven?
We're talking about a hypothetical car and neither of us (I assume) design engines like this, I'm just trying to illustrate a point about tradeoffs existing. To your own point of efficiency being a trade with durability, that's not in a vacuum. If a part is in a different location with a different loading environment, it can be more/less durable (material changes leading to efficiency differences), more/less likely to break (maybe you service the hard-to-service part half as often when it's in a harder to service spot), etc.
Only TCO matters, that is the efficiency you actually optimize for, ie dollar per mile[1]not miles per gallon.
If the car is going to need to be in shop for days needing you to have a replacement rental because the model is difficult to service and the cost of service itself is not cheap , that can easily outweigh any marginal mpg gain .
Similarly because it is expensive and time consuming you may likely skip service schedules , the engine will then have a reduced life, or seizes up on the road and you need an expensive tow and rebuild etc .
You are implicitly assuming none of these will change if the maintenance is more difficult , that is not the case though
This is what OP is implying when he says a part with regular maintenance schedule to be easily accessible.
[1] of which fuel is only one part , substantial yes but not the only one
I'm just gonna copy and paste a response to another similar comment:
The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.
Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.
This is like saying you can get a 10% improvement in battery life by changing where you position the RAM on your motherboard.
There is just no universe in which placing an oil filter in one location or another is going to make such a difference. You'd have to mount it completely outside the engine, say sitting as a cylinder on top of the hood, and even there you are not going to get a 2mpg improvement.
Sorry we're talking about a hypothetical car engine, and as an analogy to software development. I'm not an expert in designing car engines like you, but acting like this example being not fully realistic is some kind of "gotcha" for the point I'm making is really frustrating.
The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.
Based on the replies, saying there's a hypothetical 2mpg improvement to be had was a mistake, everyone is latching on to that like there's some actual engine we're investigating.
You made a "well actually" comment in which you demonstrated your lack of knowledge on the topic, _and_ stated a truism which didn't apply to the thing you were replying to.
Yes, I'm sure most people on this website have ran into seemingly bad design choices which made sense once they knew more context. But that doesn't mean that all bad design choices are like this.
Specifically dumb oil filter placement is an example of such a case where the _only_ legitimate justification is design cost saving for the manufacturer (re-using an existing design meant for a different car).
You can maybe argue that saving on design costs (and I guess also re-tooling costs) is a saving that gets passed onto the consumer. But that consumer is unlikely to feel like they're saving much money when cars depreciate faster than ice cubes in the desert, and when their oil change is 2+ times more expensive every 6 months. Really that cost savings will only really benefit the manufacturer (well, at least until they tarnish their reputation).
> Yes, I'm sure most people on this website have ran into seemingly bad design choices which made sense once they knew more context. But that doesn't mean that all bad design choices are like this.
I'm literally just saying the yin to this yang. Just because you run into a design that feels malicious doesn't mean that it always is.
Again, sorry for the sin of trying to make an analogy/example of something I'm not an expert in. You can rest easy at night knowing I'll never do it again.
You also pretty neatly laid out how re-using an existing design meant for a different car leads to some benefits to the end customer. Sure the full cost savings don't ever make it to the buyer, but there's still net wins in not spinning up new manufacturing processes (as you say). So I'm not sure why you're coming at this so combatively? Because I dared float the idea that maybe it's an engine efficiency thing we're unaware of, instead of part re-use cost/lead time efficiency improvement? Again, sorry for stepping outside of my lane...
No, the point is that the GP statement missed the point. Say we hear about a company laying off 10% of workers, and someone says "What if they needed to lay off those workers in order to meet their HIPAA obligations and protect user privacy?" Now clearly that would be an argument that is either bad faith, or just spectacularly uninformed. We do not then go on to discuss the relative importance of HIPAA compliance versus employment. The reason companies lay off workers is because of a decline in market demand or efforts at cost cutting. That is the reason. It's not to help the environment. It's not to protect customer data. It's not because this is the year of the Pig. Anyone who makes those arguments should get responded to in a way to clearly points out it is a specious argument.
The reason why automakers place serviceable parts in bad locations is due to either incompetence (If you are, say, Bentley) or malicious design (almost everyone else) -- e.g. they do not prioritize serviceability. Car makers really hate that ordinary people can repair their own vehicles. There were proposals in the 1960s to try to lock shut the hood so that car owners wouldn't be able to open it and service the cars on their own. Hyundai just announced that they will not allow car owners to retract their own parking brakes when they want to replace brake pads. You need a login with a website and prove that you are a professional mechanic before you can retract your own parking brakes. This is done, ostensibly, for "cyber security" reasons. But the real reason is that Hyundai does not want people to be able to service their own cars, they want you to take the car to a dealer. They also are not fans of independent mechanics, they would prefer if everyone that touched the car had a business relationship with Hyundai and was under contract with them. The fact that you can work on your car is an endless source of pain for manufacturers, and when they repeatedly make it hard to work on your car, or try to lock down parts so that you can't pull an old seat heater from the junkyard and use it to replace your own failed seat heater -- that is all part of the war on independent repair.
So what should be discussed is the environment of hostility to serviceability, everything from insisting that transmission oil is "lifetime" to forcing you to pay money to the manufacturer if you want to read the data from your sensors, or making it extremely hard to do simple things like changing a headlight or replacing a battery. All of that is part of the same issue, which is hostility to end user repair. It has nothing to do with improving gas mileage, or ending world hunger, or celebrating the Year of the Pig. These are all equally specious arguments.
If the engine failed due to missing oil change because of the difficulty, the whole car is gone. The waste in cost, material, and environmental impact far outweighs the savings in 2mpg improvement.
Glad to know in this hypothetical car scenario the owner decided to not get an oil change leading to the total loss of the vehicle. That seems very realistic and definitely something that car designs should be optimized around.
Or, we consider that 2mpg across 100,000 cars can save 3,500,000 gallons of gas being burned for the average American driving ~12k miles per year. And maybe things aren't so black and white. You're argument, in this hypothetical, is that negligent car owner who destroys their car because they're choosing to not change the oil is worth burning an extra 3.5millon gallons of gasoline.
I'm using this hypothetical to illustrate the point that: tradeoffs exist, and that you (we) may not have full insight into the full complexity of the trade space that the engineers were working with.
Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.
We don't have magic oil filters which last even 22k miles. You should be replacing them every 6 months / 6k miles, or 12 months / 12k miles depending on your risk tolerance (some people suggest even half my short interval).
Anyone who actually drives their car regularly will be doing an oil change at least twice a year. If an oil change takes more than 30 minutes of actual labour time of an inexperienced mechanic, it's going to be a serious financial burden which will likely outweigh any 2mpg improvement.
> We don't have magic oil filters which last even 22k miles. You should be replacing them every 6 months / 6k miles, or 12 months / 12k miles depending on your risk tolerance (some people suggest even half my short interval).
We do - they are just a lot bigger.
You should replace the oil filter when it is no longer filtering. Replacing it early is a pure waste of money. Unfortunately the tests of do you need to change the oil filter is more expensive than just replacing the filter so just replace it before it can possibly be clogged is the right answer. Generally the manufactures recommendations are correct and you should follow what they say unless you have lab results that say otherwise.
I'm just gonna copy and paste a response to another similar comment:
The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.
Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.
But to keep it concise: The core problem is that you are stating a truism in response to a famous counter-example to specifically that truism. The other problem being that you are stating a truism which everyone else is already familiar with.
Given how many people have seemingly jumped on misinterpreting the truism as me making some claim of a specific fuel efficiency improvement, I'd disagree with people being already familiar with it.
To be concise as well: it's been duly noted by me that contributing to a conversation by attempting to bring in nuance is not always well received when you make up a hypothetical for a topic people are very touchy about.
I’m no mechanical engineer, but I would assume those extreme tradeoffs occur more often when repairability is not prioritized from early iterations. I.e. “boss we’re 90% into the design cycle why are you bringing up the position of the oil filter now?”
There’s definitely a programming equivalent as well…
That is fine if you are say building a race car that will be essentially rebuilt anyway in between races, or in general where 0.1% extra performace/less weight from non-repair-friendly placement might be worth it.
The US is filled with bubble cars like everywhere else. There isn't really much difference between cars across the world. Well, China is unique with like 100 automakers all searching for customers, but for most of the world, it's Toyota, VW, Hyundai/Kia, Stellantis, GM, Renault/Nissan, Ford as the top global producers and they sell everywhere. Sure there are some special models in local markets, but those are mostly rebadged versions you can get elsewhere.
Fun Fact: Along with the "Bees are disappearing" scare, which was just measurement error, there has been an "insects are disappearing" scare, due to the fact people's windshields are not covered with bugs like they used to be. However that is because cars have gotten more aerodynamic so fewer insects are hitting the windshield.
> Along with the "Bees are disappearing" scare, which was just measurement error
Or fixed? The suspected cause at the time was pneumatic planter dust-off and addressing that was as simple as adding a baffle to direct the dust to the ground, so it was quickly adopted once identified.
You may not know this, but EVs also have oil filters and gears. They also having cooling systems. What they don't have is an engine (they have motors). But the motors have their own cooling system, and the gears have their own oil system with filters.
Every moving part - especially gears -- needs to be oiled, and whenever you are oiling metal on metal contact such as in gears, you are going to want an oil filter to catch worn metal debris, to remove it from the oil.
The difference between EVs and ICE vehicles is not that only one of them uses oil to reduce friction, but that the oil service intervals on EVs are so long that regular oil maintenance is not needed, you do it every 60,000 miles or whatever the manufacturer recommends, so it's out of mind. But that doesn't mean it doesn't require service.
Once EVs have been around for a while and there is an established market for used EVs, the people who buy them are going to want to change the oil to add more life to the EV. So it's something that is dealt with in the long-life maintenance, not the monthly maintenance. But when you do the oil service, you will curse Tesla for needing to drop the battery in order to do it, and all of a sudden you will care where things are placed and how accessible they are.
Here is a nice video -- I follow Sam Crac as one of my favorite automotive youtubers - and he picked up an old Tesla and did an oil service for it. It's a nice watch:
EVs also have consumable parts which it would be incredibly annoying to place in nonsensical locations.
The obvious one is the battery, and you can argue that modern EVs have batteries so expensive that when they are dead the car becomes scrap, and - sure, whatever.
But EVs still have: cabin air filters, coolant, brake fluid, lubricants in various places (although granted, these lubricants will mostly last the service life).
At the end of the day, as long as you have a car which moves, and not a statue, it will have things which wear out and which should be easy to replace.
I've worked at some of the "top tier" finance firms over the years.
It is absolutely astounding how much of them run on code that is:
- very reliable aka it almost never breaks/fails
- written in ways that makes you wonder what series of events led to such awful code
For example:
- A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpage open as the deployment code was in the HTTP serving code
- A workflow manager that had <1000 lines of code but commits from 38 different people as the ownership always got passed to whoever the newest, most junior person on the team was
- Python code written in Java OOP style where every function call had to be traced up and down through four levels of abstraction
I mention this only b/c the "LLMs write shitty code" isn't quite the insult/blocker that people think it is. Humans write TONS of awful but working code too.
It is completely possible that the path that got them to this point was the optimal path given their goals and knowledge at the time. And wildly enough, maybe it was even the optimal path with perfect knowledge of the future as well.
Google “hospital server room”. Guess everywhere should just do the same thing with their server rooms, yeah? Works for hospitals, and look how much money the healthcare system makes! Why even pay an IT engineer, just plug in another wire bro.
This is getting to be possibly the most irritating thing I've seen on Hacker News since registering here. Every thread about a limitation of LLMs being immediately rebuked with "humans do that too."
It's a continuous object lesson in missing the point. A similar thing happened a few hours ago when an article was posted about a researcher who posted a fake paper about a fake disease to a pre-print server that LLMs picked up via RAG, telling people with vague symptoms that they had this non-existent disease. Lo and behold, commenters go in immediately saying "I'd be fooled too because I trust pre-print medical research." Except the article itself was intentionally ridiculous, opening by telling you it was fake, using obviously fake names, fictional characters from popular television. The only reason it fooled humans on Hacker News is because they don't bother reading the articles and respond only to headlines.
It's just like your code examples. Humans fail because we're lazy. Just like all animals, we have a strong instinct to preserve energy and expend effort only when provoked by fear, desire, or external coercion. The easiest possible code to write that seems to work on a single happy path using stupid workarounds is deemed good enough and allowed through. If your true purpose on a web discussion board is to bloviate and prove how smart you are rather than learn anything, why bother actually reading anything? The faster you comment, the better chance you have of getting noticed and upvoted anyway.
Humans are not actually stupid. We can write great code. We can read an obviously fake paper and understand that it's fake. We know how hierarchy of evidence and trust works if we bother to try. We're just incredibly lazy. LLMs are not lazy. Unlike animals, they have no idea how much energy they're using and don't care. Their human slaves will move heaven and earth and reallocate entire sectors of their national economies and land use policies to feed them as much as they will ever need. LLMs, however, do have far more concrete cognitive limitations brought about by the way they are trained without any grounding in hierarchy of evidence or the factual accuracy of the text the ingest. We've erected quite a bit of ingenious scaffolding with various forms of augmented context, input pre-processing, post-training model fine tuning, and whatever the heck else these brilliant human engineers are doing to create the latest generation of state of the art agents, but the models underneath still have this limitation.
Do we need more? Can the scaffolding alone compensate sufficiently to produce true genius at the level of a human who is actually motivated and trying? I have no idea. Maybe, maybe not, but it's really irritating that we can't even discuss the topic because it immediately drops into the tarpit of "well, you too." It's the discourse of toddlers. Can't we do better than this?
I've found the users-first mentality degrading over the years at companies. It's a bit jarring too, since a lot of my early training was pretty user-centric.
I do have a feeling that the example of bigger players is carefully followed by many of the other companies, kind of as a cult of success. And that example for a long time has been rather lacking.
> But when you run your code in production, the KISS mantra takes on a new dimension. It’s not just about code anymore; it’s about reducing the moving parts and understanding their failure modes.
This sentence, itself, takes on new meaning in the age of agentic coding. "I'm fine with treating this new feature as greenfield even if it reimplements existing code, because the LLM will handle ensuring the new code meets biz and user expectations" is fine in isolation... but it may mean that the code does not benefit from shared patterns for observability, traffic shaping, debugging, and more.
And if the agent inlines code that itself had a bug, that later proves to be a root cause, the amount of code that needs to be found and fixed in an outage situation is not only larger but more inscrutable.
Using the OOP's terminology, where biz > user > ops > dev is ideal, this is a dev > ops style failure that goes far beyond "runs on my machine" towards a notion of "is only maintainable in isolation."
Luckily, we have 1M context windows now! We can choose to say: "Meticulously explore the full codebase for ways we might be able to refactor this prototype to reuse existing functionality, patterns, and services, with an eye towards maintainability by other teams." But that requires discipline, foresight, and clock-time.
Clearly, there is a thing missing here: Regulations. If you have strong regulations on how you can make money, you cannot sustainably have biz antagonize user. So in that case biz just becomes a filter for users that actually are willing (and able) to fund your software. That's a good thing.
Obviously, our regulations aren't perfect or even good enough yet. See DRM. See spyware TVs. See "who actually gets to control your device?". But still...
Oh noe, noe no.. you want to crowdsource debugging.. describe the error and your expectations, then build software by machine learning while screwing up.
Richard Brand says the most important thing to grow a successful business is to put your employees above all else. Being the place where everyone wants to work and cares about their job is the way to get the most loyal customers. Having the most loyal customers is how you make the most money over the long term.
Survivorship bias exists, but look at all the Virgin brands and at places like Google. So for a moment let’s posit he’s correct.
So, then, the problem would seem not to be capitalism generally. It would be the sort of short-term quarterly goals capitalism we see so often in recent years.
And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.
Try replacing the battery. Seems accessible enough at first, but ingenious engineering has made batteries the modern rubik's cube of auto maintenance.
I have a 2009 Citroen and the battery is secured with a bolt that is under the battery compartment and to access it you need to go under the car with a very long wrench, who engineered it is a psycho
I had a 2004 Citroen, which needed the front sidelight bulb replacing, after investigating for 20 minutes, decided to ask the garage how much it would cost next time it was in.
I left my Citroen to my mom, and my stepfather has calculated that a light bulb costs 3€, having the light bulb mounted by the mechanic costs 5€ ( including the bulb ), so to save up 2€ he decided ( with good cause ) that he will never replace the bulb himself cause it's extremely infuriating.
I did manage to replace those bulbs myself, and it's ridiculous, it has some sort of spring to hold it in place that is extremely hard to open with your fingers, and even harder to close. And on top of that you can't even see it, you have to take first pictures with your phone, understand how it works and then go entirely by tactic feedback
Since Dante wrote _The Inferno_, there has been a circle in Hell added where car designers are endlessly changing the spark plugs on AMC Javelins, bleeding brakes on Ford Escorts, and similar maintenance tasks which the design made more difficult than is reasonable.
Define "modern". I have a 2017 Civic and I've had to replace the battery a couple of times. There's a holding bar that needs to be removed before the battery can be taken out, but other than that the only real problem is the weight of the thing.
The Ford Maverick (2022+) requires removing the air intake to remove the car battery. This is fairly common across many new car models.
In general it looks like these kinds of changes are trying to make it harder for people to do this kind of basic maintenance themselves. Force you to go to the dealer.
> Force you to go to the dealer.
I recommend to never go to the dealer, unless you're going there for a warranty or recall repair. A local repair shop is always the better option. And if you don't know of a trustworthy local shop, take it to the dealer for an estimate, and then you know if the local shops are bullshitting you (they should come in way under dealer prices).
But if you happen to own a repair shop, you can make a fortune from drivers who don’t know how to do it. Wink.
Repair shop owners also don't enjoy work which is unnecessarily difficult.
Between rebuilding an engine and disassembling a bumper to replace a lightbulb most mechanics would genuinely rather be doing the lengthy but interesting work of rebuilding an engine than the lengthy and fucking boring task of disassembling a bumper to fix a lightbulb.
Moreover, even if a mechanic must charge you stupid amounts of labour cost to do a simple repair because it genuinely takes that much time, the customer might not come away with it thinking: "fuck, I bought a dumb car which is expensive to repair", they might instead come away with it thinking: "all these mechanics, quoting ridiculous prices to fix a light bulb, they must all be scammers".
Between rebuilding an engine and disassembling a bumper to replace a lightbulb most mechanics would genuinely rather be doing the lengthy but interesting work of rebuilding an engine than the lengthy and fucking boring task of disassembling a bumper to fix a lightbulb.
ChatGPT, write me a 2010-style Hacker News front page essay about how software maintenance is just like automobile maintenance, and why nobody wants low-value maintenance work to be arduous, failure-prone, and boring.
What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...
If it is a part with a regular maintenance schedule, it should be designed for maintainability.
Most maintainability conflicts come from packaging and design for assembly.
Efficiency more often comes into conflict with durability, and sometimes safety.
Right but what I'm getting at is that there can be tradeoffs that might make designing for maintainability mean optimizing for something less important to the end user.
Do you optimize an engine for how easy it is to replace a filter once or twice a year (most likely done by someone the average car-owner is already paying to change their oil for them), or do you optimize it for getting better gas mileage over every single mile the car is driven?
We're talking about a hypothetical car and neither of us (I assume) design engines like this, I'm just trying to illustrate a point about tradeoffs existing. To your own point of efficiency being a trade with durability, that's not in a vacuum. If a part is in a different location with a different loading environment, it can be more/less durable (material changes leading to efficiency differences), more/less likely to break (maybe you service the hard-to-service part half as often when it's in a harder to service spot), etc.
Only TCO matters, that is the efficiency you actually optimize for, ie dollar per mile[1]not miles per gallon.
If the car is going to need to be in shop for days needing you to have a replacement rental because the model is difficult to service and the cost of service itself is not cheap , that can easily outweigh any marginal mpg gain .
Similarly because it is expensive and time consuming you may likely skip service schedules , the engine will then have a reduced life, or seizes up on the road and you need an expensive tow and rebuild etc .
You are implicitly assuming none of these will change if the maintenance is more difficult , that is not the case though
This is what OP is implying when he says a part with regular maintenance schedule to be easily accessible.
[1] of which fuel is only one part , substantial yes but not the only one
I'm just gonna copy and paste a response to another similar comment:
The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.
Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.
This is like saying you can get a 10% improvement in battery life by changing where you position the RAM on your motherboard.
There is just no universe in which placing an oil filter in one location or another is going to make such a difference. You'd have to mount it completely outside the engine, say sitting as a cylinder on top of the hood, and even there you are not going to get a 2mpg improvement.
Sorry we're talking about a hypothetical car engine, and as an analogy to software development. I'm not an expert in designing car engines like you, but acting like this example being not fully realistic is some kind of "gotcha" for the point I'm making is really frustrating.
The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.
Based on the replies, saying there's a hypothetical 2mpg improvement to be had was a mistake, everyone is latching on to that like there's some actual engine we're investigating.
You made a "well actually" comment in which you demonstrated your lack of knowledge on the topic, _and_ stated a truism which didn't apply to the thing you were replying to.
Yes, I'm sure most people on this website have ran into seemingly bad design choices which made sense once they knew more context. But that doesn't mean that all bad design choices are like this.
Specifically dumb oil filter placement is an example of such a case where the _only_ legitimate justification is design cost saving for the manufacturer (re-using an existing design meant for a different car).
You can maybe argue that saving on design costs (and I guess also re-tooling costs) is a saving that gets passed onto the consumer. But that consumer is unlikely to feel like they're saving much money when cars depreciate faster than ice cubes in the desert, and when their oil change is 2+ times more expensive every 6 months. Really that cost savings will only really benefit the manufacturer (well, at least until they tarnish their reputation).
> Yes, I'm sure most people on this website have ran into seemingly bad design choices which made sense once they knew more context. But that doesn't mean that all bad design choices are like this.
I'm literally just saying the yin to this yang. Just because you run into a design that feels malicious doesn't mean that it always is.
Again, sorry for the sin of trying to make an analogy/example of something I'm not an expert in. You can rest easy at night knowing I'll never do it again.
You also pretty neatly laid out how re-using an existing design meant for a different car leads to some benefits to the end customer. Sure the full cost savings don't ever make it to the buyer, but there's still net wins in not spinning up new manufacturing processes (as you say). So I'm not sure why you're coming at this so combatively? Because I dared float the idea that maybe it's an engine efficiency thing we're unaware of, instead of part re-use cost/lead time efficiency improvement? Again, sorry for stepping outside of my lane...
No, the point is that the GP statement missed the point. Say we hear about a company laying off 10% of workers, and someone says "What if they needed to lay off those workers in order to meet their HIPAA obligations and protect user privacy?" Now clearly that would be an argument that is either bad faith, or just spectacularly uninformed. We do not then go on to discuss the relative importance of HIPAA compliance versus employment. The reason companies lay off workers is because of a decline in market demand or efforts at cost cutting. That is the reason. It's not to help the environment. It's not to protect customer data. It's not because this is the year of the Pig. Anyone who makes those arguments should get responded to in a way to clearly points out it is a specious argument.
The reason why automakers place serviceable parts in bad locations is due to either incompetence (If you are, say, Bentley) or malicious design (almost everyone else) -- e.g. they do not prioritize serviceability. Car makers really hate that ordinary people can repair their own vehicles. There were proposals in the 1960s to try to lock shut the hood so that car owners wouldn't be able to open it and service the cars on their own. Hyundai just announced that they will not allow car owners to retract their own parking brakes when they want to replace brake pads. You need a login with a website and prove that you are a professional mechanic before you can retract your own parking brakes. This is done, ostensibly, for "cyber security" reasons. But the real reason is that Hyundai does not want people to be able to service their own cars, they want you to take the car to a dealer. They also are not fans of independent mechanics, they would prefer if everyone that touched the car had a business relationship with Hyundai and was under contract with them. The fact that you can work on your car is an endless source of pain for manufacturers, and when they repeatedly make it hard to work on your car, or try to lock down parts so that you can't pull an old seat heater from the junkyard and use it to replace your own failed seat heater -- that is all part of the war on independent repair.
So what should be discussed is the environment of hostility to serviceability, everything from insisting that transmission oil is "lifetime" to forcing you to pay money to the manufacturer if you want to read the data from your sensors, or making it extremely hard to do simple things like changing a headlight or replacing a battery. All of that is part of the same issue, which is hostility to end user repair. It has nothing to do with improving gas mileage, or ending world hunger, or celebrating the Year of the Pig. These are all equally specious arguments.
ok, glad you seem to have everything figure out so definitively
If the engine failed due to missing oil change because of the difficulty, the whole car is gone. The waste in cost, material, and environmental impact far outweighs the savings in 2mpg improvement.
Glad to know in this hypothetical car scenario the owner decided to not get an oil change leading to the total loss of the vehicle. That seems very realistic and definitely something that car designs should be optimized around.
Or, we consider that 2mpg across 100,000 cars can save 3,500,000 gallons of gas being burned for the average American driving ~12k miles per year. And maybe things aren't so black and white. You're argument, in this hypothetical, is that negligent car owner who destroys their car because they're choosing to not change the oil is worth burning an extra 3.5millon gallons of gasoline.
To be fair, you are constructing an entirely hypothetical car scenario where oil filter placement leads to a 5-10% increase in fuel efficiency.
We're already in the land of the fucking ridiculous. Let's have fun with it.
I'm using this hypothetical to illustrate the point that: tradeoffs exist, and that you (we) may not have full insight into the full complexity of the trade space that the engineers were working with.
Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.
We don't have magic oil filters which last even 22k miles. You should be replacing them every 6 months / 6k miles, or 12 months / 12k miles depending on your risk tolerance (some people suggest even half my short interval).
Anyone who actually drives their car regularly will be doing an oil change at least twice a year. If an oil change takes more than 30 minutes of actual labour time of an inexperienced mechanic, it's going to be a serious financial burden which will likely outweigh any 2mpg improvement.
> We don't have magic oil filters which last even 22k miles. You should be replacing them every 6 months / 6k miles, or 12 months / 12k miles depending on your risk tolerance (some people suggest even half my short interval).
We do - they are just a lot bigger.
You should replace the oil filter when it is no longer filtering. Replacing it early is a pure waste of money. Unfortunately the tests of do you need to change the oil filter is more expensive than just replacing the filter so just replace it before it can possibly be clogged is the right answer. Generally the manufactures recommendations are correct and you should follow what they say unless you have lab results that say otherwise.
I'm just gonna copy and paste a response to another similar comment: The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.
Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.
You can also read my reply in my other comment.
But to keep it concise: The core problem is that you are stating a truism in response to a famous counter-example to specifically that truism. The other problem being that you are stating a truism which everyone else is already familiar with.
Given how many people have seemingly jumped on misinterpreting the truism as me making some claim of a specific fuel efficiency improvement, I'd disagree with people being already familiar with it.
To be concise as well: it's been duly noted by me that contributing to a conversation by attempting to bring in nuance is not always well received when you make up a hypothetical for a topic people are very touchy about.
I’m no mechanical engineer, but I would assume those extreme tradeoffs occur more often when repairability is not prioritized from early iterations. I.e. “boss we’re 90% into the design cycle why are you bringing up the position of the oil filter now?”
There’s definitely a programming equivalent as well…
That is fine if you are say building a race car that will be essentially rebuilt anyway in between races, or in general where 0.1% extra performace/less weight from non-repair-friendly placement might be worth it.
Not for normal car
Except..there is never such reason. They can put the filter anywhere in the pipeline. Some even have it exactly where it should be: https://www.ifixit.com/Guide/2013+Subaru+Legacy+Oil+and+Oil+...
Most cars sold in the US are not aerodynamic so it seems a couple of mpg isn't the focus anyway
The US is filled with bubble cars like everywhere else. There isn't really much difference between cars across the world. Well, China is unique with like 100 automakers all searching for customers, but for most of the world, it's Toyota, VW, Hyundai/Kia, Stellantis, GM, Renault/Nissan, Ford as the top global producers and they sell everywhere. Sure there are some special models in local markets, but those are mostly rebadged versions you can get elsewhere.
Fun Fact: Along with the "Bees are disappearing" scare, which was just measurement error, there has been an "insects are disappearing" scare, due to the fact people's windshields are not covered with bugs like they used to be. However that is because cars have gotten more aerodynamic so fewer insects are hitting the windshield.
https://en.wikipedia.org/wiki/Decline_in_insect_populations?...
Um I’m pretty sure that’s not the only evidence for insect population declines.
> Along with the "Bees are disappearing" scare, which was just measurement error
Or fixed? The suspected cause at the time was pneumatic planter dust-off and addressing that was as simple as adding a baffle to direct the dust to the ground, so it was quickly adopted once identified.
I think oil filter located somewhere sinful usually in cars that are aerodynamically sound.
The real issue is that oil filters and gears are really just legacy design. EVs don’t need them.
So, similar with software design, as in other fields, often a problem goes away when you ask a different question.
You may not know this, but EVs also have oil filters and gears. They also having cooling systems. What they don't have is an engine (they have motors). But the motors have their own cooling system, and the gears have their own oil system with filters.
Every moving part - especially gears -- needs to be oiled, and whenever you are oiling metal on metal contact such as in gears, you are going to want an oil filter to catch worn metal debris, to remove it from the oil.
The difference between EVs and ICE vehicles is not that only one of them uses oil to reduce friction, but that the oil service intervals on EVs are so long that regular oil maintenance is not needed, you do it every 60,000 miles or whatever the manufacturer recommends, so it's out of mind. But that doesn't mean it doesn't require service.
Once EVs have been around for a while and there is an established market for used EVs, the people who buy them are going to want to change the oil to add more life to the EV. So it's something that is dealt with in the long-life maintenance, not the monthly maintenance. But when you do the oil service, you will curse Tesla for needing to drop the battery in order to do it, and all of a sudden you will care where things are placed and how accessible they are.
Here is a nice video -- I follow Sam Crac as one of my favorite automotive youtubers - and he picked up an old Tesla and did an oil service for it. It's a nice watch:
https://www.youtube.com/watch?v=l0ZNHKjHalY
EVs have gears and gear oil in their drive units. There is a reduction gear that needs lubrication, as well as the differential.
They actually will need oil changes starting anywhere from the 50k to 100k mile mark.
Here's the maintenance guide with pictures walking through changing the oil and filter for the Rear Drive Unit (RDU) in a Tesla Model S:
https://service.tesla.com/docs/ModelS/ServiceManual/Palladiu...
EVs also have consumable parts which it would be incredibly annoying to place in nonsensical locations.
The obvious one is the battery, and you can argue that modern EVs have batteries so expensive that when they are dead the car becomes scrap, and - sure, whatever.
But EVs still have: cabin air filters, coolant, brake fluid, lubricants in various places (although granted, these lubricants will mostly last the service life).
At the end of the day, as long as you have a car which moves, and not a statue, it will have things which wear out and which should be easy to replace.
Engine oil and oil filters are just an example.
I've worked at some of the "top tier" finance firms over the years.
It is absolutely astounding how much of them run on code that is:
- very reliable aka it almost never breaks/fails
- written in ways that makes you wonder what series of events led to such awful code
For example:
- A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpage open as the deployment code was in the HTTP serving code
- A workflow manager that had <1000 lines of code but commits from 38 different people as the ownership always got passed to whoever the newest, most junior person on the team was
- Python code written in Java OOP style where every function call had to be traced up and down through four levels of abstraction
I mention this only b/c the "LLMs write shitty code" isn't quite the insult/blocker that people think it is. Humans write TONS of awful but working code too.
> LLMs write shitty code
LLMs regurgitate shitty code. They learned it entirely from people.
> Python code written in Java OOP style where every function call had to be traced up and down through four levels of abstraction
To be fair, the standard library `unittest` and `logging`, along with the historic `distutils`/Setuptools stack, are hardly any better.
Which is great until you have to make changes to this kind of code, not to mention a massive refactoring.
It is completely possible that the path that got them to this point was the optimal path given their goals and knowledge at the time. And wildly enough, maybe it was even the optimal path with perfect knowledge of the future as well.
That's the opposite of 'great'. Good code is that which can be refactored.
I would not call "you must leave the webpage open" a "working code" :)
This looks like an example of biobackend: defective IT compensated by humans
Your point is very sane, of course, shitty code was not invented now. But was it ever sold as a revolution ? Probably, too !
Google “hospital server room”. Guess everywhere should just do the same thing with their server rooms, yeah? Works for hospitals, and look how much money the healthcare system makes! Why even pay an IT engineer, just plug in another wire bro.
This is getting to be possibly the most irritating thing I've seen on Hacker News since registering here. Every thread about a limitation of LLMs being immediately rebuked with "humans do that too."
It's a continuous object lesson in missing the point. A similar thing happened a few hours ago when an article was posted about a researcher who posted a fake paper about a fake disease to a pre-print server that LLMs picked up via RAG, telling people with vague symptoms that they had this non-existent disease. Lo and behold, commenters go in immediately saying "I'd be fooled too because I trust pre-print medical research." Except the article itself was intentionally ridiculous, opening by telling you it was fake, using obviously fake names, fictional characters from popular television. The only reason it fooled humans on Hacker News is because they don't bother reading the articles and respond only to headlines.
It's just like your code examples. Humans fail because we're lazy. Just like all animals, we have a strong instinct to preserve energy and expend effort only when provoked by fear, desire, or external coercion. The easiest possible code to write that seems to work on a single happy path using stupid workarounds is deemed good enough and allowed through. If your true purpose on a web discussion board is to bloviate and prove how smart you are rather than learn anything, why bother actually reading anything? The faster you comment, the better chance you have of getting noticed and upvoted anyway.
Humans are not actually stupid. We can write great code. We can read an obviously fake paper and understand that it's fake. We know how hierarchy of evidence and trust works if we bother to try. We're just incredibly lazy. LLMs are not lazy. Unlike animals, they have no idea how much energy they're using and don't care. Their human slaves will move heaven and earth and reallocate entire sectors of their national economies and land use policies to feed them as much as they will ever need. LLMs, however, do have far more concrete cognitive limitations brought about by the way they are trained without any grounding in hierarchy of evidence or the factual accuracy of the text the ingest. We've erected quite a bit of ingenious scaffolding with various forms of augmented context, input pre-processing, post-training model fine tuning, and whatever the heck else these brilliant human engineers are doing to create the latest generation of state of the art agents, but the models underneath still have this limitation.
Do we need more? Can the scaffolding alone compensate sufficiently to produce true genius at the level of a human who is actually motivated and trying? I have no idea. Maybe, maybe not, but it's really irritating that we can't even discuss the topic because it immediately drops into the tarpit of "well, you too." It's the discourse of toddlers. Can't we do better than this?
I like the final conclusion. And sadly I don't feel like anything changed for the better on this topic since 2023.
I am afraid that without a major crash or revolution of some sort, user won't matter next to a sufficiently big biz. But time will tell.
I've found the users-first mentality degrading over the years at companies. It's a bit jarring too, since a lot of my early training was pretty user-centric.
I do have a feeling that the example of bigger players is carefully followed by many of the other companies, kind of as a cult of success. And that example for a long time has been rather lacking.
This is definitely true. In growth companies there is way more emphasis these days on investor hype over user centricity.
For companies that have a solid competitive moat they have at best gotten lazy about user centricity and at worst actively hostile.
> But when you run your code in production, the KISS mantra takes on a new dimension. It’s not just about code anymore; it’s about reducing the moving parts and understanding their failure modes.
This sentence, itself, takes on new meaning in the age of agentic coding. "I'm fine with treating this new feature as greenfield even if it reimplements existing code, because the LLM will handle ensuring the new code meets biz and user expectations" is fine in isolation... but it may mean that the code does not benefit from shared patterns for observability, traffic shaping, debugging, and more.
And if the agent inlines code that itself had a bug, that later proves to be a root cause, the amount of code that needs to be found and fixed in an outage situation is not only larger but more inscrutable.
Using the OOP's terminology, where biz > user > ops > dev is ideal, this is a dev > ops style failure that goes far beyond "runs on my machine" towards a notion of "is only maintainable in isolation."
Luckily, we have 1M context windows now! We can choose to say: "Meticulously explore the full codebase for ways we might be able to refactor this prototype to reuse existing functionality, patterns, and services, with an eye towards maintainability by other teams." But that requires discipline, foresight, and clock-time.
Once I wrote the perfect piece of software. It was so perfect that there was literally no bugs for months.
How could this have happened? Well, the code was shipped but no customer was running it in production.
Software dev would be so easy without the customers
Clearly, there is a thing missing here: Regulations. If you have strong regulations on how you can make money, you cannot sustainably have biz antagonize user. So in that case biz just becomes a filter for users that actually are willing (and able) to fund your software. That's a good thing.
Obviously, our regulations aren't perfect or even good enough yet. See DRM. See spyware TVs. See "who actually gets to control your device?". But still...
> Regulations. If you have strong regulations on how you can make money, you cannot sustainably have biz antagonize user.
If that's what the regulators are optimizing for.
Stupid regulations are why we have an idiotic cookie banner on many websites.
Oh noe, noe no.. you want to crowdsource debugging.. describe the error and your expectations, then build software by machine learning while screwing up.
Does the ">" mean "greater than" or is it meant to symbolize an arrow in a ordered sequence?
Good question, to my it was "greater than" but now I read it again with the other interpretation ... and it still makes sense? Weird.
More important than:
"We arrived at a little model that expresses the relative importance of various factors in software development..."
It went on the good track, but failed to generalize that ≹ is what apply among all these terms.
yes, run by machines, read by humans. so ?
Richard Brand says the most important thing to grow a successful business is to put your employees above all else. Being the place where everyone wants to work and cares about their job is the way to get the most loyal customers. Having the most loyal customers is how you make the most money over the long term.
Survivorship bias exists, but look at all the Virgin brands and at places like Google. So for a moment let’s posit he’s correct.
So, then, the problem would seem not to be capitalism generally. It would be the sort of short-term quarterly goals capitalism we see so often in recent years.