How Software Engineers Are Different Than Auto Mechanics

[hossman]

As a general rule: fixing bugs in software isn't just about changing code, it's about cleaning up any crap the older (broken) code may have created. We don't have the luxury of an auto-mechanic who might replace a leaky oil valve and happily ignore all of the oil that car has already leaked all over the highway. When we fix bugs, we have a responsibility to go out and scrub up all that oil.

Ask yourself: does the oil valve still has a leak (somewhere)? Did you clean up all of the spilt oil? If you think the valve doesn't currently leak, then cleaning up the oil will be the end of it -- but if there is still a leak, at least cleaning up the oil will give you a clean road to spot any future oil spills.

(This rant comes from a comment I made to an existing "bug" at my company involving bad data in our DB, which one of my coworkers decided needed to be saved for posterity in our documentation on good software development practices (after fixing my typos of course). I figured I might as well share it here as well)

[BrowserUk]

I dunno.

In a previous life I was a Mech.Eng. in an auto factory. There was a problem that came up on the track with a part in the engine bay failing to seat properly because it was fouling on a small lug on the bracket that held it. This only affected a small percentage of the vehicles of thatt type because the lug in question was most often on the other side of the bracket and so didn't interfere. The re-work required was minimal as the lug was only a few millimeters high and was easily filed away--though it did require the paint to be touched up.

As an apprentice, I got to follow the process of tracking down the cause of the problem and its rectification.

The first solution was to have the guy who fitted the brackets, check and reject those where the lug was on the wrong side.

The second solution was to have the guys who loaded the bare metal brackets into the dip painter check and file the errant lugs off before they were dipped.

The third solution tracked it back to the place were the individual parts of the bracket were spot-welded together. Here they discovered the reason for the problem. The gig that was used to hold the pieces whilst they were spot-welded was worn, which meant that the lug that was intended to ensure that the piece it was on would only fit into the jig one way around was no longer effective for that purpose.

The discussion on what to do about this ranged from:

• replacing the gig--too expensive for a vehicle that was nearing the end of it's production life.
• Repairing it. Also expensive due to the nature of the gig and the metal (a special type of bronze) that it was made from.
• Having the guys who loaded the gig double check each other that the part was loaded correctly. Awkward because if it was wrong, it meant unloading the gig and resetting it.
• Having them file the lug off if the noticed the lug was incorrect as they unloaded--better, but still quite tiime consuming.

  Then one of the spot-welder operators suggested: Why not modify the press tool that punches out the piece with the lug on it, so that it doesn't have a lug?

  We can't do that! What would stop the piece being inserted the wrong way around?

  :)

[brian_d_foy]

Maybe you haven't watched the auto industry enough. When a car company messes up, they end up recalling the car, settling lawsuits, and responding to new government regulation.

I would say the automobile engineers (not mechanics!) actually have a tougher job than softwaree engineers. Software is relatively easy to change. Once the car is out of the factory, it pretty much what it is even if the gas tank explodes on impact. Car manufacturers put a lot of thought into making cars, car parts, tools for cars, and so on. How many software people do you know who do that much planning? Car makers literally demolish their cars to see if they'll kill people. They do all sorts of other tests that probably put to shame any software testing suite.

I think you wrongfully blame the auto mechanic, who doesn't even belong in this analogy. He didn't design the car. He didn't sell the car. He didn't even tell you to use the car. He just fixes the problem you tell him to fix when you bring your car to him. Software writers ("engineers", feh!) are different than mechanics because one creates a mess and the other fixes messes. It's not a luxury, and I think you're unfair to auto mechanics to imply that they are disinterested and feckless workers.

I don't feel any responsibility to clean up problems other people's bugs create, either. If I came in as a maintenance programmer, I see bug-fixing and data-cleansing as separate jobs, the same way that an auto mechanic sees fixing your car and cleaning up your oil mess as separate jobs. If a car has a bug, that's the car company's problem, not the mechanics.

I think you'd do much better to not make any comparison and simply tell people to clean up their own disasters. It's not about which occupation is better than other, it's just taking responsibility for one's actions.

[DrHyde]

How many software people do you know who do that much planning?

Plenty. They work in fields like medical devices, railway signalling, and all kinds of other places where software can kill.

[chromatic]

There are other differences, too. Quoting (myself) from Extreme Programming Pocket Guide:

There's a word for software that cannot be changed after delivery. That word is hardware.

[sfink]

Where I work, we tend to have many short-term installations in trade shows. No network access, and you can't turn it off to fix it in the middle of the show. After delivery, you're not changing any software. You're not even going to get to change any configuration. It had better work, or somebody's going to be getting their money back.

Seems like platform game programming must be somewhat similar, so I don't think I have a completely niche perspective.

On the other hand, if something does break in the middle of a show, we usually blame it on the hardware. So maybe I'm agreeing with you after all!

[bilfurd]

I feel your pain, brother

I got into a long argument with my boss about a sizable percentage of our data that was irrelevant, useless, impossible to map (bit of a normalization problem), and skewing the results of several reports. To make matters worse, he could not tell me how the data was entered into the database. I took the position of archiving it if you must, but cleaning it out of the database. He took the position of "it's the only information we have."

I tried to be patient and failed. I finally offered a compromise: I would clean out the database and create a script to generate as much wrong data as he needed whenever he needed it. We do, in theory, have an infinite amount of bad numbers. Also, there is a non-zero chance that random data may actually produce the correct results, while bad data would never be correct.

Long story short, he pulled rank and I lost the battle.

The most difficult part was explaining to the new hires why the data was in there and watching them argue the same case and lose.

On the bright side, the doctor prescribed some meds that have really helped my stress level.

[inman]

In a slight twist to the tale, the modern motor mechanic is becoming more like a software engineer. Gone are the days when a bloke armed with an oily rag and a socket set could work on your car. Nowadays, the first thing that they do is wire up your car to a diagnostics machine or plug their laptop into the engine management system and start a download.

On the other hand, there are days when I want to set about my code with a wrench...

[Anonymous Monk]

Scrub up all that oil? Say you have written a utility to burn CDs, are you going to reburn all the broken CDs if it turns out the utility had a problem? Reprint all the pages if your printer driver has a bug?

Anyway, I wish software engineers were more like car manufactures. No car is build without a design. No cars are delivered without being properly tested. The average car is better tested than most CPAN modules (ever seen a CPAN module with an actual stress test?). Most countries require by law that cars are tested - unlike software.

I think the software world can learn a lot from the car industry. (Not that I'm saying the car industry doesn't have its share of problems).

[zentara]

The distinction won't be here for very much longer. I heard a "news blurb" on the TV where some IBM spokesperson says that cars of the future, will be programmed just like a personal computer. I sure hope they are "linux compatible", and we are not force to buy cars pre-loaded with MS-Windows.

It would be cool if we could run them with Perl. The electric motors used in the new eco-cars, are well-suited to be computer-controlled variable speed drives.

[BrowserUk]

I have no problem with my car running Linux, but god I hope that they find a replacement for make and Configure.

The idea that I am going to have to pullover, run Configure and then re-build the whole thing in order to adjust my seat position, the electric mirrors or close the sunroof when it starts raining scares me sh...illy.

Gives a whole new meaning to "Making cars" and home-builds :)

[itub]

You will usually need to run configure and make once, and that will be done at the factory, so only car hackers will worry about it. Afterwards you just need to edit ~/.carrc, or, if you want the changes to affect all users of the car, /etc/carrc . :-)

[wolfger]

I have no problem with my car running Linux, but god I hope that they find a replacement for make and Configure.

Portage! I want to check for upgrades to my car every night when I come home from work! I think having a Gentoo Jeep would be awesome. :-)

[Anonymous Monk]

I don't have a problem with make or configure.

What I would find scary is cars driving on the street that could be programmed by anyone. That's far more scary than whatever OS it might be running (which I strongly doubt will be Windows or a Unix flavour).

[hardburn]

I'd rather not see either one used. There are already thoughts of using Bluetooth-enabled cars as a potential virus infection path. Having a few different systems makes it more difficult to write a single virus that can infect all the cars on the road.

Monocultures are inheirantly unstable, wheather it's Windows, GNU/Linux, *BSD, or Irish Potatos.

[zentara]

Well you have to admit, that an OS with a "protected root filesystem", will be safer than any Windows solution. Of course, the police will probably like Window's cars, they will be able to cut your motor, with a single mouse click. (And probably listen to your conversations thru the backdoors to the microphone). :-)

So I would not doubt that Windows is used for exactly that reason, touting "increased public safety" as the rational. Of course, Microsoft will have "fine print" on every car sales receipt saying " we are not responsible for any accident , injury or death due to the wild viruses which are known to affect their OS".

[DentArthurDent]

At a fundamental level, whether or not you should clean it up depends on one key ratio. That ratio is the danger that it causes related to the time and effort it would take to clean up. If the data being there is largely innocuous, and it would take a lot of effort to clean it up, then you leave it. On the other hand if the data is deadly to the task at hand, and it's easy to clean then obviously you do clean it up.

The tipping point should be determined by the load on the bandwidth of the people who can clean it up. If they're all straight out with no bandwidth left, then it will take a lot more danger to get it cleaned up.