Hacker News new | past | comments | ask | show | jobs | submit login
What a Year at a Mechanic Shop Taught Me About Process (2016) (atomicobject.com)
72 points by philk10 on Nov 16, 2019 | hide | past | favorite | 51 comments



Software development sure would be a lot simpler to manage if it were like auto repair, where every bit of work is well scoped, short, with absolute boundaries and near complete independence from any other work happening.

Perhaps I'll think lessons from an auto repair shop can apply to software development after they've spent 2 years rebuilding a vehicle from the inside out while it continuously journeys across the interstates.

https://i.imgur.com/cD8Y7fh.mp4


I think you’re over simplifying auto repair work. Sure, sometimes it’s an oil change, which is short, well scoped, etc... But a lot of times it’s “Sometimes, when I’m turning left, the car makes this noise... you know, like a whining grinding popping noise. It’s not doing it today though.” And you don’t know if it’s a 5 minute fix or a 5 day investigation and replacement of major drivetrain parts...


Auto repair is 90% diagnostics and 10% wrench turning. A lot of newer vehicles have symptom matrixes with a process for repair. Lowering the skill floor for mechanics.

What’s interesting to me about auto repair is how techs are paid. A lot of shops do book rate. Example let’s say you have to replace a front half shaft. Book rate pays you for 30min. If you take an hour to do it - you lose money.


HVAC repair starts getting into black magic territory. Giant, incredibly dynamic systems with hard physics, positive/negative feedback loops, control theory operating with very few inputs and very uncomfortable humans dripping sweat on the back of your neck while they watch you work.

I feel like everyone that frequents HN would have a good time spending a year working in that industry.


I've had a tangential interest in the physics / mechanics of air-conditioning since working in an office with two people on opposite ends of the "comfortable temperature" scale, and noticing that one of them opens their window in order to "solve the problem". I've since noticed various other people open windows to try to "fix" the air-conditioning temperature.

My assumption is that opening the window fucks it up for the whole system, but very few people are aware of this, and the office folks aren't made aware of it by the air-con techs.

Am I way off? Am I overstating the effect that an open window has on the system?


It will upset the building balance at a minimum. Air balancing techs are typically a different discipline from HVAC in large commercial spaces.

Leaving the window open and AC on in high humidity areas can freeze up the coil generating a service call, trick zone sensors, etc. If there is a large temperature difference the sharp gradient will not be comfortable.


I never worked on very large systems, mostly small commercial and residential. A buddy of mine supervises HVAC for a large commercial facility and we were talking about their makeup air. Basically it sounded like the building is effectively hermetically sealed until the makeup air vents open because of interior pressure or O2/CO2 levels. Seemed kind of creepy that there was some active system in charge of that. How do you know when it's not working?


The same CO2 sensors that call for make up air are hopefully monitored. Sick building syndrome.

Buildings are poorly sealed in my experience. In California code requires economizers on RTUs and they are almost always broken / stuck partially open. In the Inland Empire for example the actuators bind up from sand and often seize. Nobody wants to pay to fix just that, if they even know it’s busted.

I stay under 10 tons. Things are different in bigger buildings!


>Auto repair is 90% diagnostics and 10% wrench turning. A lot of newer vehicles have symptom matrixes with a process for repair. Lowering the skill floor for mechanics.

That’s unfortunate because nobody actually knows what is doing and everything is fine as long as it falls in the guidelines, if they found a problem that is not “in the books” they have no clue how to proceed and this problem not only applies to mechanic shops, i’ve seen the same situation in the medical field.


The skill floor is under the house: I have a 3-series BMW that was having odd engine hesitation but not throwing any codes. The dealership's mechanics could not fix it! They ended up throwing a ludicrous amount of parts at my car including some very expensive items such as a new transmission, new transfer case, new fuel injectors, plugs, coils, fuel pump, wiring harness. The bill, which was covered by the warranty, totaled over $10,000 and they still had not fixed the issue. They finally called in a guy from an Audi dealership and he fairly quickly diagnosed the problem as a faulty oxygen sensor. They had the car for nearly 60 days while I drove a brand new 4-series loaner car. So BMW did right by me, but holy crap I have never ever seen such lousy troubleshooting!


They'll just wait until it breaks. My car clanks sometimes when doing sharp turns at a low speed. Something in the steering or wheels. Not very loud, but disconcerting. 2 visits to the dealer - zero progress. To be fair, it's probably harmless. Or it could crap out at 80mph and kill me, I don't know. And that's BMW, where mechanics are expensive AF.


Is it a 'tuk tut tut tut tuk' sound? If so, try going to a parking lot and holding the wheel all the way to the left and accelerating slowly in a circle. same for the right. If it makes that noise it's most likely your CV axles. If it's only when you hit bumps then it may be a ball joint that is coming loose.


Take it to a non-dealership? My (slight) expérience with the BMW dealership is that they’re mindless flow-chart followers that can’t/won’t use their brains to think.

They certainly didn’t read my notes that indicated that I already swapped around the plugs and coils but the problem stayed in the same cylinder.

Their first course of action was to replace all plugs and coils.

Ugh.


Was it warranty work?

They are going to do it the way that makes sure they get paid.


Nope, well out of warranty.

Ultimately, they missed out on a lot of work. Actual issue was a broken exhaust valve spring.

Indy got the same notes as me, immediately did a compression test and easily knew it wasn’t plugs/coils.


Software development is more like manufacturing engineering. Auto repair is probably closer to working an operations ticket, only without all of the fancy telemetry and diagnostic tools, and a lot more bloody knuckles.


The OBD port can tell you a lot. Especially if you can google it to get pointed toward the more common failure modes that lead to code XYZ.


Lots of shops do ground up builds.

I think it's also not the case that software development is so heroic, most deployment strategies draw a line between development and the version people are using, and there is quite some power in the ability to go back to a previous version.


I'm beginning to think the real answer for software development is to stop wanting a process. A team either clicks, or it doesn't. I think this happens no matter what process is attempted.

EDIT: Obviously there should be acceptance criteria for the product, especially where safety is a concern; but the day-to-day process is just going to be what it is.


I don’t understand why some areas would warrant the response of “sometimes it works and sometimes it doesn’t”. What if we left other areas examined? “Let’s not bother to research sorting algorithms further. Some people write a sort and it goes fast, and some people write one and it goes slow, and that’s just the way it is”.

If a team can just “click”, isn’t it critically important to figure out why this occurs, so we can create other teams that click? It would be an awful shame if we were not as a species able to make effective use of all of us because we preferred to leave this to chance.


I think it's just very hard to generalize from the performance of a combination of people that each have unique personalities and abilities. It's hard to even know what to measure.

For a sorting algorithm, you know what to analyze, and you know the result is generalizable.


No one has even bothered to use Fred Brooks' recommendations in nearly 50 years, despite praising his book up and down without reading it.


Eventually everything will be sealed in lego like blocks. We will then stop calling software technology.


That’s called hardware. The whole point of software is that it’s soft.


How far away from that do you think we are and why?


It wont happen overnight (if at all). For hardware we are already there. We use a single cpu or video card that just works and cant be matched by combining a bunch of smaller components. We do have instances trying to combine the 2.

We also have lots of and continue to have more software monoliths that at first are just to good, one wouldn't bother writing their own. Later we wont even remember how to do it and end up with a final design. Could be epic, could be aweful. (I mean every ready made thing available for use either for end users or programmers)

Why? Software is a fantastic prototyping tool, its so good we don't bother making things into a chip. This for the most part because we wouldn't be able to update it. The need for updates will eventually go away. Things for now continue to be improved but at some point it stops making sense to do so. What [say] an email application should look like was completely unknown in the 80's but we all have expectations today. It seems unlikely for us to continue to write [say] new email clients from scratch forever?


I was surprised by "It was really interesting to work in an industry that was completely different from technology."

Cars aren't technology? When did the term get redefined to mean software?


You are of course technically correct, but it’s pretty well established at this point in time that the “tech sector” refers to IT and Internet companies. Taken to the extreme, you can technically call pretty much all human endeavors “technology”, so you need to follow current conventions in order to have a productive discussion.


Words often go through phases where they stop meaning what they mean to groups of people. Sometimes large groups. “Feminism” is the classic example in my head.

You don’t have to bend to that. People often try to destroy words for political reasons, but in then end, I think, the words often stand resilient.

Our languages are really impressive structures that define real spaces. There is power to learning them and knowing how to use them well.

That power does diminish when words are abused, but it doesn’t disappear.

Personally, I am happy to have words be refined, but when people try to redefine them to the point where they are useless... I listen, and parse their words as intended, but I keep using those words correctly with others.


Perhaps I should have considered that this forum would use your definition. I do believe that technology is much broader than IT and internet. The author didn't refer to the tech sector, by the way.


I've been going through a now-decade-long rethink on this topic. It's pretty clear that there are 1) fields and 2) levels of technology.

A decent encyclopaedia or technical school course catalogue will lay out most of the basics (library classification systems are another good option), and models vary. I've been devising my own based on mechanisms rather than application areas. The MIT course catalogue itself is a fascinating artefact.

The levels of technology also matter: there's cutting-edge, high, middle, low, and primitive. Examples such as "Low Tech Magazine" and the "Primitive Technology" YouTube channel are excellent opportunities for enlightenment (and also surprisingly and reassuringly popular).

The domain most at HN are familiar with is the higher end of information technology, itself a very narrow subset, though one which touches on many others through its interactions with communications, media, control, monitoring, surveillance, and manipulation.


I prefer to call all human inventions technology, because even if a technology is old, it's still serving its purpose. Even if we're taking it for granted.

Plumbing put us all out of the water carrying business. But without it, daily life would be very, very different.

Google's definition of technology is interesting. - the application of scientific knowledge for practical purposes, especially in industry. - machinery and equipment developed from the application of scientific knowledge.

I guess technology is the process of making technology. Pipes are a technology, but most of technology is over.

But it also sounds like technology when a plumber is applying his knowledge of metal and fire and gravity to solve a new problem.


When people say they work in "technology" they're really shortening it from "high technology" (or perhaps "technology development".) This makes it a useful distinction; if you take it literally, everyone's working in technology one way or the other.


> When people say they work in "technology" they're really shortening it from "high technology" (or perhaps "technology development".)

I think what they really mean is “computing”, and mostly specifically “software”; I rarely see any other industry or type of work, no matter how high tech and whether or not the work being done is tech development, referred to as “technology” without some other modifier.


Most "technology" companies are a different environment than an autoshop.

The difference was economics and scale where the work applied to thousands to millions of customers, while an auto shop would 1:1


I’m a developer but have built a side gig renovating 100 year old homes. My partners in the effort are a carpenter who can do pretty much anything and a former machinist who can take anything apart and put it back together (whether that’s a motor or a house). He recently completed a vr6 engine swap on a gen-ii golf. What the article mentions about the parallels with the auto body shop and agile are true. We don’t intentionally run it this way it just organically works like this. Over two years of doing this we’ve had numerous conversations about how the mind of a carpenter or fabricator is very much like the mind of a developer. You have to visualize the problem, evaluate multiple approaches and then ultimately work uninterrupted to create the solution.


Do you have a blog or an instagram? I’d love to read more about your work; I imagine many others here would too.


I never thought of that.. you know another way Reno’s are like software... you often have to debug other people’s work. Simple example, in one house there were wide door jams that met in the middle of the top of the door frame. Why would anyone do that. Turns out, you take the two long pieces and the two short pieces and you get two 96” pieces... answer, they didn’t want to buy a third piece of lumber. Now to tell you how really stupid this is, you buy lumber at Home Depot by the foot and they even have a saw station in the store for you to trim pieces and even if you didn’t trim there you can bring the unused portion back and get a credit. Now... I would bet most software devs on here have seen code equivalents at least as dumb as that. It’s been fun doing this but it’s been cool to see just how many parallels there are.. don’t get me started on the 1x, 10x, 100x analogues!


Curious to know how often you or the carpenter replace mud sills on 100 year old homes.


Hah, haven’t seen any myself but I’ll ask him. Why do you ask?


since the mud sill connects the house to the foundation (on a wood-framed house at least) it is often the most heavily damaged and awkward to repair, but if it is squared away properly then later work is built on the same ground truth. I am wondering what the analog for mud sills is within software, i.e. what do you have to get right at the start to ensure that your later work won't need to be reworked?


Data modelling. The data model pervades any given piece of software, so it's hard to change. If there are mistakes in it, you will see workarounds all throughout a codebase.


I’d agree with this. All the action in a house happens in the basement. It’s here where you see the mechanicals and all the wiring and plumbing decisions. It’s where you see if there’s water or radon leaks or structural issues. And it’s the part of the house least understood by the user / typically it’s a scary/foreign place to be. So yeah that sounds just like the data model!


Read the 12 Agile principles and replace software with cars, development with mechanic. It all makes a lot of sense because they're general business principles.

Comparing it to Scrum is pretty inaccurate, though. Scrum is designed to deliver a unit of shippable work over weeks; auto mechanics ship every day. Mechanics work much closer to an Agile kanban-based tech desk, where you have a pool of random requests to execute as efficiently as you can, and you pull new work from backlog as you go. None of this "oh I can't pull in / take out that work, it would throw off the sprint". Every day is a sprint. And most every job that has coordinated high-paced work has a morning meeting.


Good points, I think the author of this article draw parallels to closely. That auto shop had good routines that's all. A bunch of them don't have good routines but instead have good enough ones and they can still manage and get by if there are not too many competing car services around. In software development it would often mean that the business won't succeed because you are competing at almost a global scale and location means little or nothing to your customers unless of course you're in SV.


I used to be a biomedical engineering technician before becoming a software dev, and I have to say I somewhat miss the immediate positive feedback from actual users when you solve a problem. If anyone feels similar after moving into software -- what do you do to keep your motivation up?


1. Find a metric you care about 2. Graph that metric 3. Be happy when you deploy something that makes the graph better


Would love if anyone could elaborate on the difference between a manager and a coordinator within the shop.


I've been looking for similar dev relevant discussions of traditional manufacturing or ops processes - any other favorite articles?


That's a very well run auto shop.


tl;dr: healthy organizations act humanely.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: