I've been a reader of the Embedded Muse for a couple years now - despite not being an embedded developer. I am amazed how similar the issues in embedded systems are to those in computer games/simulations!

Anyway I am currently taking a break from engineering and I have discovered that there are things other industries know that perhaps engineering could benefit from. Maybe these are known in bigger companies, but as a junior software developer in a small company, they were new to me.

If you are rushing the planning has failed.
My current work is in the conservation sector. We deploy pest traps to catch invasive animals, roam around forests removing pest plants, and monitor native bird populations. A lot of the time the work site is far enough away from civilisation that people are out of cellphone reception - sometimes for days at a time. As you may expect it is moderately hazardous work and the remoteness increases the risk. Because of this, a prominent company put together an incident database (aka bug tracker) and gradually mitigated injuries involving chainsaws, poisons, and people getting lost. Now their two major hazards are driving and people slipping/tripping. Some bright spark then realised that these are symptoms of an underlying cause: rushing. Driving is more of a hazard the more of a rush a person is in, and a person running is more likely to fall over. As a result this company promotes the idea: "Don't rush, if you are rushing the planning has failed."
A lot of effort in engineering goes into fixing software bugs, but the easiest way to fix a bug is not to have it in the first place. I wonder what percentage of bugs would be "fixed" by the philosophy of "don't rush" or how much better software would be if developers had less stress. Let's face it, you'd rather fly in a spaceship designed by a relaxed engineer than a rushing stressed one!

Is a bug on a developers machine a "near miss"?
Because incidents are physical injuries rather than failing software, this same company has decided: every person has the right to go home injury free at the end of the day. For this to happen the company has realised that: "The only acceptable target is zero injuries", and they try to get as much information about possible incidents as they can. It's very easy to go "bugs will happen" and try fix them when they do, but does anyone aim for zero bugs right from the developers chair? How different would it look if software engineers decided that any bug, even in versions local to their machine (that got fixed before review) was unacceptable? You'd have to be very sure of what you were doing before you typed a line of code.

Where does a bug become unacceptable? Clearly a bug in a product is a problem, and a bug in the mainline VCS is also an issue, but bugs on your local machine are considered OK. I guess bugs stop being acceptable somewhere just before code review time? Are bugs a manifestation of a misunderstanding? Could we try to tackle bugs while they are in developers heads rather than when they reach a computer? After all, a bug caught at code review is a near miss to having a bug in your product.

Iterate on science rather than on engineering
One of my side hobbies is 3D printing, and some issues encountered in software development are evident in the hobbyist 3D printing area. With 3D printing, it's easy to alter, share and manufacture new parts, so the simplest way to do things is to "iterate lots" - print out dozens of parts and progressively debug the physical part until a working solution is reached. Is this engineering or is it hacking?

Iteration of a part is needed when research is coupled with development. Engineering occurs when there is adequate scientific understanding before design work begins. Prototypes are used to validate a concept, not to design it.
If the shipbuilding industry can build ocean liners without iterating on multi-thousand-tonne-hulls, could software engineers produce production quality code without iterating? If you view a software developer as a guy with a welder, current development seems to involves a lot of hacksaw work. How many lines of code survive from first commit all the way to product release? 

I got interested in TTL and CMOS design and taught myself enough to build my own custom interfaces.  But I finally took the remaining leap into microprocessors and micro-computers with the Z-80.  Attached are a couple of photos of a rather dense board I designed and wire-wrapped for an S-100 bus, CP/M based system.  (The board came back to me a decade later after a research computer was decommissioned.)  The idea was to fit "everything" except CPU, RAM, and floppy disk controller onto one board.  So you'll see configurable power-on jump circuitry, a pair of 8251's for serial communications (with RS-232 level shifting and jumper-customizable handshaking), a pair of parallel ports using 74LS244's (as I recall), and an 8253 counter-timer for getting msec reaction times.  The screw stand-off's on the backside corners were for a piece of perf-board that protected everything from errant fingers and such.

Ah, back when a logic probe and a 'scope were all you needed to troubleshoot a system!  The hard part was bootstrapping -- if you designed the circuitry, wired the board, wrote the low-level "monitor" and burnt it into the EPROM yourself, a failure to boot could be literally anywhere in the system.

It's pretty amazing these things worked as well as they did, considering the noise.  Lots of bypass caps soldered in everywhere!