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
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.
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
In this case, I couldn't see how to get at the bulb without either losing lots of skin or dismantling half the front end of the car - so I was happy to pay the half hour rate they charged. I believe they went in from below the car with something to reach it and mirrors.
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.
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...
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.
> 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.
102 comments
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
The battery is in a compartment in the left front wheel well. You have to remove that wheel to access the battery.
I was instantly impressed by the pure creativity and artistic expression the team employed for that design.
All of them have been in Ford (or Saturn).
So, similar with software design, as in other fields, often a problem goes away when you ask a different question.
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.
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.
How could this have happened? Well, the code was shipped but no customer was running it in production.
> 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.
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...