Automotive engineering is antediluvian wrt process compared to software engineering.<p>We can manufacture billions of copies of our product with error rates that are almost too small to measure. Six sigma? Hah!<p>Our design processes are far in advance of the automotive industry. Continuous design is normal practice. It's only the most careful (or most backward) shops that'll take months to update a design.<p>The automotive industry, by comparison, regularly takes years to update a design even by a minor version. The best shops at this i.e. the F1 race teams can fix bugs in days, minor releases in months and, if this season is anything to go by, struggle horribly with major version upgrades.<p>TL;DR it's fallacious to compare manufacturing to programming. The latter is a design process even if it feels superficially like an assembly line sometimes.<p>One final point. I would have very much liked to have read an analysis regarding the different approaches of the engineers vs the craftsman. This is an interesting topic and does have crossover between disciplines. Oh well...
First, I appreciate this story, but it seems the author compares the build process of software to the production process of the car line.<p>It's comparing the build stage vs the literal produce-the-thing stage.<p>I also think the stoppage of the production line happens in software.<p>If my code breaks while in production, I grab as many log files and stats as I can, roll back the code, deploy, and then study exactly why everything failed, and if we recovered post rollback.<p>That seems like the similar case on the car production line - haul the faulty model aside (get the logs/metrics), figure out exactly what happened, fix it.<p>Who knows how the actual assembly line was put together. Maybe they iterated hundreds of times.<p>I don't expect my code to fail in production, otherwise I wouldn't have put it in production, but I understand it _may_ fail. That's why I put in logging and metrics collection, the same way those engineers hauled aside the car.
I hate these articles that compare software engineering to traditional engineering because the typical software engineer has very different requirements wrt failure and budget than does the traditional engineer. There are examples [1] of software being written up to the standards of traditional engineering. It can be done, it's just very expensive and it almost always makes more sense financially to write software that's more likely to have bugs. When that doesn't make sense, more disciplined practices are used.<p>[1] <a href="http://www.fastcompany.com/28121/they-write-right-stuff" rel="nofollow">http://www.fastcompany.com/28121/they-write-right-stuff</a>
<p><pre><code> [...] a whole bunch of engineers tried to figure out not how to
fix the problem but why the problem happened in the first
place.
</code></pre>
This is exactly what debugging is.<p><pre><code> My friend was quite obviously an accomplished hacker.
His hacker mentality would have fared quite well in
software production, where debugging is part of the
normal workflow [...]
</code></pre>
Finding a workaround in production is not debugging even if it's useful.
Humans in advanced production lines are "actuators". They are not there to think, but to replace an hypothetical machine that it's not possible to build yet. We have those magical machines in software, we call them compilers, interpreters, operative systems, file systems, etc.<p>I still have memories of my pass by Uni and how a Software Engineering professor constantly refered to programmers/developers as "coders" or "monkeys". He never stopped of repeating to us, day after day, that we shouldn't program ever. Our job as engineers was to plan, design, assess and manage those "monkeys".<p>More than 15 years of professional career later, my initial suspicion have been confirmed one time after another: those professors from Uni need a good deal of fresh air and to get in touch with the reality, instead of spend the day pontificating like celibate catholic priests about what you can and cannot do in your bedroom.<p>I know that many people here love Dijkstra and people like him, and even enjoy to feel their intellectual whipe in their mind, reading their essays and feeling bad about themselves as the essays repeat constantly how that everything is wrong and broken in the software profession.<p>For those people, I suggest to read "To Engineer is Human" by Petrosky and learn about how real engineers really work.
Comparing the production line for F1 with your average software shop is an unfair comparison.<p>If you are ready to pay the same amount of money - you can get the same level of quality in software too.<p>The problem is most people do not even think software should cost anything.
Software is created once. If it runs on more than one computer, it's just copies of the actual result of that one time creation. If it's improved with new features, then that's a new unit, itself created once. The effort goes into the creation of the one thing, not the copies. Version 1.1 is not version 1.2.<p>This observation is often used to point out that "software is different" from cars and other hardware. Cars and hardware have lots of chances for defects, but software copies are essentially perfect. Assembly line products are not copies like a package or disk is a copy; each finished unit has lots of effort in it.<p>But if you still want to use the hardware example, find what the equivalent products are. A lot of effort goes into physically assembling a car, and then the car cranks out transportation.<p>A lot of effort goes into physically assembling a software team, and then the team cranks out software.<p>And while of course there are profound differences between a car an a human team, it might be useful to put engineering resources into designing and producing a team.
I try to take this kind of approach with my own work. My workload is really light, so every task I get, I take the opportunity to dig into the task and the business needs surrounding the tasks so that I can come up with a solution that works, is stable, can be extended when needed, and doesn't require a lot of maintenance.<p>When an issue comes up, the first thing to do is to put together a workaround, a way for business to continue in absence of a proper fix. I then, without the need to rush, dig into the issue, figuring out a way to reproduce it, then isolate it, then fix it in a way that makes the whole system more robust and not less.<p>Having worked on the codebase / infrastructure this way for two years, my workflow is pretty-well refined. For my current issue, I'm devising a command-line tool to download and parse the log files to give me exactly the info I need to run down web issues. I can yak-shave to my heart's content.
Always thought formal methods were an attempt to achieve this.<p>However the biggest obvious difference that prevents dev becoming like an engineering assembly line is that the engineers on the line are not surrounded by car customers changing how the car should or shouldn't work/look/cost every two weeks.<p>Not that cleaning up the actual process of development so its more easily and naturally verifiable wouldn't be a good thing.
I run a company which develops medical devices, many of which combine mechanical, electronic and software engineering. It's well known (and a running joke) that software engineers from non-medical fields think it is acceptable to ship their product with serious defects. It takes a long time and a lot of training to get them up to the level that we need, more so than for mechies and sparkies.
I think the author misses the point of their own story, this isn't an software vs regular engineer thing, this is a problems with monotonous static jobs.<p>His friends job is to fit one small body panel on the chassis, over and over again.
So when he gets one that doesn't fit his instinct is to make it fit as opposed to asking why it doesn't. His job isn't questions, his job is to fit it on.<p>When he was working in his own body shop this hacker wouldn't have stood for his tools putting out misprints and mistakes, but then his job was managing the whole shop.<p>Static monotony gets static monotonous thinking.
This is more about production lines vs one offs than engineering vs hacking.<p>Civil engineering is real engineering but jobs are usually unique. Problems in civil engineering projects are usually 'debugged' and 'patched' on site without going all the way back and revisiting the original design.
Engineering is at its heart is both an applied science and a methodology for it's application. So yes, software engineering is a valid form of engineering. We're taking computer science principles and applying them to a practical application. We don't write papers, but we use the knowledge to drive industry.<p>So there's this topic of failure analysis, and we don't always do this well in the world of software engineering. We don't like to analyze our failures probably as much as we should, possibly because we find them embarassing, or perhaps they might be bad PR if they were known. So we just want to get the fix done and move on.<p>But the thing is for most software it doesn't matter how we deal with bugs, and that's because they cause minor problems. But when it comes to loss of life or money, bugs do matter. Doctors and lawyers have professional boards that oversee actions and disputes. Airplanes and Trains have the NTSB that oversee accidents and engineering failures. Civil engineers study the collapse of bridges as part of an effort to make bridges safer.<p>Failure in those cases are bad.<p>If my software solution is off by a few bugs, meh, so what? It doesn't cost the company money, usually. And it probably didn't kill anyone, and it probably just fixed some small css issue that looked great on firefox, but bad on chrome...
Software engineering isn't an assembly line. In our case, the assembler, is quite literally a program that virtually never makes mistakes. When a program won't compile, as would be analogous to this McLaren case, we do stop everything and figure out why it won't.
> I wonder how many years until software production will reach the level of maturity where we don’t just fix bugs but, when bugs happen, we stop in our tracks, shocked that bugs happened at all in the first place<p>This happens all the time in software engineering. Less because we're shocked that bugs <i>could</i> happen, and more because when you are working from the assumption that what has happened should not be possible, when it happens, that means your mental model of what is happening within the system is wrong in some way.<p>There are the bugs you understand (or think you understand), and those you can safely allow workarounds for in most cases, because you understand the scope of the problems. Then there are the bugs that you don't understand, and it's important to be very careful and provide them the attention they deserve, because while they may be simple fixes, they could just as likely be an insidious case of data corruption or loss that you weren't ware of.
The big difference is that the software industry still gets away with the consumer paying for defects. This is where the auto industry was in about 1952.
I've been in dev shops where, when a NULL turned up in a database column where it wasn't expected, the site was rolled back to a previous version, people were called in on the weekend, and a group of engineers spent hours trying to figure out why that NULL got there and how to stop it from happening again. It's not like a DBA couldn't have just run a quick UPDATE query to clean up the null in a matter of seconds...<p>I see this as indicative that debugging production issues happens in non software engineering contexts as well, in spite of the fact that we're always told that their processes and procedures are so much more mature and robust than ours.
"He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible..."<p>Software engineering is so far removed from other facets of engineering that comparisons to poetry make for better discussion.
I think the author is mistaken. No two car companies or software companies are the same.<p>The software written for mission critical systems, such as nuclear reactors and even cars (think direct injection, ABS, AWD and now auto-cruise control systems) goes through an extensive series of evaluations. Same goes for the software that helped New Horizons reach Pluto and beyond. It's just not possible to achieve such feats without a thorough software development process.<p>Agreed that the same cannot be said for startups, but comparing a startup to a multi-billion dollar car company with tonnes of regulatory and compliance checks is not a fair comparison to say the least.
I think that this also happens in every place where mission critical software is developed.<p>But here is our dirty little secret - none of the software 99% of us write is mission critical. And probably 75% of it is never used.
This was actually "debugging the program",
as the running program is the manufacturing process,
and the coding and development is the engineering and design.<p>Still, software systems are both more fragile and can easily be more complex than real-world systems, so the naïvity is actually trying to apply engineering processes with rigid "design" phases and handoffs to complex software processes.<p>(As seen in the software, in just about every car.)
As a civil engineer I am seeing a lot of ignorance on the part of the hackers towards the physical sciences, especially the author.<p>Software debugging has 2 parts:<p>a) find the bug - lucky for you a machine does this step automatically<p>b) fix the bug - once the bug is found this is self explained<p>Industrial debugging has 2 parts:<p>a) find the bug - requires going on the production floor and measuring things<p>b) fix the bug - once the bug is found this is self explained<p>How are they different?
Seems like the hacker wanted to patch the problem, whereas the engineers wanted to fix the root cause. I don't think either is wrong; you might want to patch the issue first and then fix the root cause. Or you might suspect the root cause is simple enough to fix and not spend extra time on the workaround. Or you may never find the root cause.<p>The reason why there's a lot of bugs in software is that software is soft. People know that changes can be tested with relative ease, and they also have a good idea of how wrong things will go if they do go wrong, and quite often an error is tolerable. This means we can often play a bit more loosely with correctness and reliability in order to gain some speed.<p>There's plenty of software problems where this isn't the case, and you end up with a very different process.
The OP is mistaking manufacturing for design. The manufacturing phase of software - compilation - is hugely efficient, reliable, and cheap. The industry certainly does "drop tools" and see what has happened when a compiler like GCC screws up, which is a better analogy here.
When issues occur in my code, I do identify the root cause but then try to see if it may occur elsewhere in my code and how to prevent similar issues in the future. And I know lots of coworkers who do the same. I don't think this is a major engineering insight but common sense.
Some big software companies operate like the engineering companies described in the article but it's often not a good thing.<p>I've worked for a software company where it would take almost a week to add one new property to a JSON object because there was 3 different sets of tests I had to write/update across multiple code repos and it involved the coordination of multiple teams across multiple cities.<p>I've also worked for startups were it would take me an hour to make a similar change on my own but with lighter (albeit just as effective) test coverage.<p>It all comes down to company processes and approach to risk.<p>I think the lean approach is much more efficient if you have a good/experienced engineering team which you trust and who actually care about the product.
The assembly-line story would be way more like software dev if it had a prelude where the installer repeatedly pointed out that the panels didn't fit and was told "well, we bought them from the vendor so use them anyways". :)
> I wonder how many years until software production will reach the level of maturity where we don’t just fix bugs but,<p>If Google tried to figure out why the hard drives fail in every server, how many years before we could type McLaren in the search box ?<p>Instead they embraced a different truth - things fail, so we'll build our systems to handle that.<p>And I think this is the reason why we can get away with bugs in software - because we can isolate and prepare for components failure or imperfections.<p>So instead of trying to absolutely NOT introduce any bugs, we can instead focus on making our systems fault-tolerant and introspective and handle all errors in a graceful way.
The problem is that unlike with "regular" engineering, there are mathematical theorems that basically say that writing bug-free code is somewhere between prohibitively expensive and impossible. The cost of proving a non-trivial program property has a proven lower bound of O(S) where S is the number of states the program may take; alternatively, we say that proving correctness is <i>at least</i> PSPACE-complete (if not EXPTIME) in the size of the program. Not saying we can't do our best and use various tools, but this cost cannot -- in general -- be reduced to anything acceptable, and therefore we will never be shocked when a bug does occur.<p>It is easier to achieve string AI than to write bug-free code, and even that won't help: a super-intelligence will still have bugs in the code it writes.
This is what happens if the compiler glitches or the os fails; people dig in to find out why. Normal code is much more like doing a service - if the breaks don't fit it's because the person fitting them has screwed up, and you take them off and fit them (or a new set) back on again. Maybe there is an inquest in the team about using spanners properly, maybe the old fella in the shop tries to communicate some wisdom about checking things first.<p>At the end of the day it's about money and risk.<p>But, the interesting difference between software and mech eng isn't the attitude to faults, it's the fact that software isn't designed to work within tolerances. We don't build software around dimensions or stresses, we expect it to work <i>always</i> like maths, but it isn't, quite.
Don't fix a production issue by 'hacking' in the solution live on production. Figure out what caused it and fix that. At least, that's what we do for our software.
if software were like that hacked jeep, it wouldn't be so bad. lot of software looks is like this: <a href="https://benahrens.com/wp-content/uploads/2014/03/how-to-be-more-productive.jpg" rel="nofollow">https://benahrens.com/wp-content/uploads/2014/03/how-to-be-m...</a>
One not-terrible way to start on your bug-free crusade would be to switch to functional programming languages and styles and "pure" functions.<p>Having done 10 years of OO before I began coding in a functional style and realized all the benefits, this is my experience talking.