Haptics brings a personal touch to technology - <AUTHOR> http://news.bbc.co.uk/2/hi/technology/10373923.stm

<comment><USER2> The Motorola A1000 was a touch screen phone with haptics back in 2006 - was a GREAT phone, was gutted when it died.</comment>


Here's what it would take for self-driving cars to catch on - <AUTHOR> http://www.washingtonpost.com/blogs/wonkblog/wp/2013/10/23/heres-what-it-would-take-for-self-driving-cars-to-catch-on/ <comment> loup-vaillant So:

Bad press. Being killed by a machine is _soo_ much worse than being killed by a fellow human. This won't be a problem. Yes, it will make the news, but if self driving cars turn out to be more reliable than human drivers, the numbers will show, and the insurance companies will follow. (Funny how talks about not controlling your car will die out in the face of monetary savings.)

Liability. Self driving cars are not the only thing that kills people when it goes wrong. Think airliner software. I think we'll get over it. Also, current cars already face similar challenges. I recall a sticky pedal problem that caused some Japanese cars to speed up until death ensues. As far as I know, unlike some unlucky drivers, the company is still alive.

Law. Not a big problem, as long as self driving cars are legal _somewhere_. Once they have demonstrated their worth, other states and countries will follow very quickly.

Privacy. It kinda sucks, but it won't matter one bit. If people _really_ cared about not giving away their trip data to some for-profit corporation, they wouldn't be using Facebook in the first place. Or Gmail.

Price. It will inevitably go way down. Self driving is a software problem. A human driver could manage with only a couple web cams. So will programs, as they get better. Not to mention economies of scale.

Unemployment. Here be Unions. But they won't stop the advent of self driving cars. Driver-less companies will simply drive the Driver-full companies out of business. Unlike rail-road companies, they don't own the tracks. Now this _will_ raise unemployment unless we do something about it. (Enforcing a 4 day work-week would be a good start.)

Overall, I expect all those problems to set us back about a decade, 15 years tops. But they won't even arise until we actually start selling those cars.

<comment><USER3> You are oversimplifying a lot of the problems. And saying that the problems won't even arise until we start to sell these cars is just nonsense.

Also enforcing a 4 day work-week? How does this lower unemployment, except on the paper? And keep in mind this solution would come with it own bag of problems, like administrativ overhead for more employees etc.

<comment><USER4> And each employee making less money but cost of living not going down. With more administrative overhead wage would decrease or the cost of living would increase in order for companies to keep the same profit margins.

<comment> loup-vaillant Actually, no. By employing more people, you can cut the money you need for unemployment insurances. You can actually have your cake and eat it too.

[https://news.ycombinator.com/item?id=6618615](https://news.ycombinator.com/item?id=6618615)

</comment></comment></comment></comment><comment><USER5> All I want _right now_ is a "traffic jam" button, where driving in congested traffic (speeds under 30 mph) on a straight road are taken care of by an AI. This is a much simpler problem to fix and can help with a transition rather than some sort hard switch.

</comment><comment><USER6> One of the things I'm really excited about with self-driving is that it will tilt the economics towards car pools rather than car ownership.

Currently everyone has to buy cars that will be suitable for any journey they might have to make. This means that people commute to work in cars that can take a whole family on holiday. Self-driving would mean you could always get the most suitable car for the journey you're about to make. Perhaps you're feeling tired and want to sleep on the way to work? Maybe you want to do some work so you'd like a desk? Put your feet up in an entertainment centre?

Self-driving will become popular because it will mean the end of wasting hours of your life watching the car in front of you. Just think of the ads, what could you do with an extra 3 hours a day?

<comment><USER4> I'm not sure it will encourage car pools. People will still want the comfort of having your own car with your personal music, temperature settings, privacy, etc.

<comment><USER7> I don't think he meant car pools in the sense of multiple people for 1 car. I think he meant pools of cars--multiple cars available for 1 person, depending on that person's needs at the moment.

<comment><USER6> Yeah, zipcar was what I had in mind.

</comment></comment></comment></comment><comment><USER8> Okay some thoughts:

1) Some roads can have sensors embedded in them. People would have to get an account to drive on them (eg EZpass or SelfDrivingCarID). The sensors would recognize a self-driving car and allow it on the road. Those roads could have 200mph speed limits. Cars attempting to enter the road which arent self- driving, or too old of a version, would not be able to pass the tollbooth, and will be fined for attempting to and wasting everyone's time at one of the booths.

2) Parking tickets and metermaids should go the way of the dodo. Cars can easily be detected at the side of a curb, and the money deducted from the EZPass or whatever account. Instead of parking, though, you'd just timeshare your cars in a demand based marketplace (type of car, time you need it for, what the demand is for those hours etc) and then clean them up when you get out. They'll go on to pick up the next passengers.

<comment><USER9> The lower economic class will use the self-driving self-cleaning taxis.

The middle class will have their own cars and use high-efficiency parking. It will be no hardship to use a short, tight slot six blocks away.

The upper class will have their own cars and good parking. Some will even have "drivers", because babysitting a fancy car is one of the less unpleasant ways for the "driver" to earn his negative income tax credits.

<comment><USER8> By the N I T are you talking about Milton Friedman's proposed system?

</comment></comment></comment><comment> martin-adams My gut feeling is that it will take longer that we expect for it to be wide stream.

I am extremely curious how far off the technology is to drive on less than predictable roads, such as narrow streets of London during rush hour or in the small villages of Yorkshire in the UK.

I love how the article refers to lives saved, whereas I always said, "we will allow computer driven cars when the number of accidents/lives lost will be less than those caused by humans". It goes to show that the nature of driving is now out of anyone's hands and we accept there are fatalities, akin to disease. With this acceptance is the race to save lives, rather than have preventable loss.

>> And roughly 40 percent of fatal accidents are caused by alcohol, distraction, drugs or fatigue. Letting robots take the wheel would save lives.

The part that I find interesting is that if you are in control over whether to drive with alcohol, distraction, drugs or fatigue (at least for the car you travel in); you can affect your chances of being in a fatal accident. With computers at the wheel, you don't have control and accidents become the lottery of driving. Unless of course, control over your fate is now down to whether you install the latest firmware update on your car.

I do believe that mainstream driverless cars will happen and future generations will look back at human driven cars like riding horses - <USER2> done for recreational purposes and not for long distances.

<comment><USER10> >I am extremely curious how far off the technology is to drive on less than predictable roads

I don't know which aspects of roads you are considering, but there are few unpredictable roads nowadays, thanks to street view

<comment> martin-adams I'm referring to parked cars on the left with oncoming traffic on the right, adding driveways with vehicles entering and a wall on the right hand side of the road.

I'm referring to really tight corners which you can't do it in a single turn and have to reverse back, all while there is potential for oncoming traffic.

I'm referring to single lane country roads with passing points every few hundred yards and having to reverse back to accommodate a vehicle or tractor coming the other way.

I'm referring to blind corners where the only way to know if it's clear is to watch for no cars between the visible gaps in a hedge or between cars.

I'm referring to the guy in the middle of the road with the road works sign saying waving you to go or to stop.

I really mean the less than predictable conditions on the roads.

Stuff like this:

Cars on left: [https://www.google.co.uk/maps/preview#!q=holmfirth&data=!1m8...](https://www.google.co.uk/maps/preview#!q=holmfirth&data=!1m8!1m3!1d3!2d-1.782294!3d53.567125!2m2!1f328.2!2f83.7!4f75!2m7!1e1!2m2!1shyNnYnK19Ptbn2fzyWAxDA!2e0!5m2!1shyNnYnK19Ptbn2fzyWAxDA!2e0!4m15!2m14!1m13!1s0x487bc4ceed38a29b%3A0x807d7a8131476d90!3m8!1m3!1d100097!2d-1.4004929!3d50.9138216!3m2!1i1920!2i955!4f13.1!4m2!3d53.571744!4d-1.786292&fid=5)

Sharp turn: [https://www.google.co.uk/maps/preview#!q=laithe+avenue&data=...](https://www.google.co.uk/maps/preview#!q=laithe+avenue&data=!1m8!1m3!1d3!2d-1.818507!3d53.557762!2m2!1f268.42!2f73.96!4f75!2m7!1e1!2m2!1sBwN7Jici9iUbFzo1gF1oow!2e0!5m2!1sBwN7Jici9iUbFzo1gF1oow!2e0!4m15!2m14!1m13!1s0x487bda9b8e913e43%3A0x7f746b9d85fdf3ee!3m8!1m3!1d23571!2d-1.8124635!3d53.5673161!3m2!1i1920!2i955!4f13.1!4m2!3d53.555649!4d-1.8160425&fid=5)

Pulling out onto this road: [https://www.google.co.uk/maps/preview#!data=!1m8!1m3!1d3!2d-...](https://www.google.co.uk/maps/preview#!data=!1m8!1m3!1d3!2d-1.864395!3d53.495086!2m2!1f244.94!2f82.17!4f75!2m7!1e1!2m2!1sHHMWT0D74ngmWnkdsy1HLA!2e0!5m2!1sHHMWT0D74ngmWnkdsy1HLA!2e0&fid=5)

I'm not saying it's impossible, but I know it's not easy.

<comment><USER11> I'd expect them to drive themselves most of the time, but not always. On some places you'd have to "switch to manual" and drive the car yourself to a place where the gps tells you that it's suitable to turn on automatic driving.

</comment></comment></comment></comment><comment><USER12> This article is overly focused on cost, which is dumb because they're in development. Clearly costs will not be the same when they become generally available, and the ownership model is going to change completely, too. Car service on demand will largely replace car ownership.

</comment><comment><USER13> Self driving cars are only going to work where not only every vehicle has sensors that communicate with each other but also the roads themselves will have to be retrofitted with sensors.

The only two places self driving cars have a future are:

1\. Planned communities which ban the use of personal cars inside that community. 2\. An interstate highway system where there is a special lane dedicated to self driving cars.

If google is serious about self driving cars, they need to buy or build a town... or use this one.

[http://theweek.com/article/index/219043/the-ghost-town- being...](http://theweek.com/article/index/219043/the-ghost-town-being-built- as-a-science-experiment)

[edit]

The best hope for self driving vehicles is as an anti-social public(or public- ish) transportation system.

<comment><USER14> Why do you assume self driving cars have to communicate with other cars to be effective? The cars already have sensors far more advanced than us humans have.

And why would the roads need sensors?

I do believe it would benefit self driving cars to have areas where only they are allowed, and in the future I foresee that being the case as the cars can drive faster and closer together if not driven by a human. But this shouldn't be a necessity when cars gets more advanced.

Progress is fast and if history has showed us anything it's that history is impossible to predict. About 100 years ago flight was thought as an impossibility until the Wright brothers proved us wrong and look where we are today.

In 100 years what role will self driving cars have? I'm certainly leaning toward it being mainstream, even considered normal, to see them everywhere.

Then again, some would say we would have flying cars by then.

<comment><USER4> If there are three cars beside each other

A B C

Car A is driven by a human and steers into car B. If car B could communicate with car C it could ask it to move over (or slow down) so that it (car B) can move out of the way of car A.

<comment><USER14> Oh yes, if cars would communicate they would behave better. But they don't _have_ to do that to be effective.

If A B C are all driven by humans, C could move over or slow down if it sees that B is steering into it. But self driving cars could do that as well.

That self driving cars could communicate is an argument for the self driving car, not against it as the parent made it out be.

</comment></comment></comment></comment><comment><USER15> Another issue may be whether or not consumers want to be seen in one of Google's self-driving cars.

The vehicles' outlandish appearance doesn't bother me because I'm a long-time advocate of self-driving cars, but it may be an issue for other consumers.

Other car manufacturers such as Cadillac are working toward fully autonomous vehicles that look like stylish, regular cars. The computers and sensors are hidden in a spare tire compartment.

I wonder if Google is underestimating consumers' preference for traditionally good-looking vehicles. I think about how the company was criticized for underestimating the aesthetic roadblocks involved in the Google Glass rollout.

<comment><USER16> I cannot imagine that google wants to rollout the current iteration of their self driver car at scale to consumers. They want they technology sorted out and for that phase of it, they do not care what the car looks like and you cannot assume that's how their self driving cars will always look.

<comment><USER15> Google's technology depends on a series of lasers attached a large, spinning rotor on the car's hood. Cadillac and GM's technology does not: [http://www.pcworld.com/article/254192/cadillac_self_driving_...](http://www.pcworld.com/article/254192/cadillac_self_driving_cars_out_by_2015_.html)

</comment></comment></comment><comment><USER17> [http://lesswrong.com/lw/gfv/notes_on_autonomous_cars/](http://lesswrong.com/lw/gfv/notes_on_autonomous_cars/)

</comment><comment><USER9> Much of a car's weight is safety cages and crumple zones. Leaving out all that superfluous metal will save lots of money.

<comment><USER18> Build cars out of airbags, with 4 wheels attached, each with their own battery pack, accidents would be almost fun</comment></comment>


Data visualization design and the art of depicting reality - <AUTHOR> http://www.moma.org/explore/inside_out/2015/12/10/data-visualization-design-and-the-art-of-depicting-reality/ <comment><USER2> "Why Should Engineers and Scientists Be Worried About Color?"

[http://www.research.ibm.com/people/l/lloydt/color/color.HTM](http://www.research.ibm.com/people/l/lloydt/color/color.HTM)</comment>


Eyecatch, CI for UI/UX, is now in private beta - <AUTHOR> https://eyecatch.io <comment><USER2> Hi, I am the project leader of Eyecatch. We are currently accepting users in our private beta, and would love to have your feedback. Let us know what you think!</comment>


Multiplication using just one AND gate - <AUTHOR> http://www.pentodepress.com/receiving/stochastic-computing.html

<comment><USER2> The output would be a pulse train though, not a discrete value.

You could average that out with a capacitor (which would introduce some latency), then sample the input of the capacitor and output the resulting number. The problem with that approach is that you'll end up with less significance than you'll need for most applications (getting a 10 bit a/d to work reliably is pretty tricky, more bits is voodoo).

By the time you follow all this to its logical conclusion I think you'd end up with operational amplifiers.

Analogue computers exist, and even existed before digital ones in a certain fashion.

They are much more tricky to build and are not as universal as digital computers.</comment>


Ask HN: My company is being acquired. How can I maximize my upside as an IC? - <AUTHOR> The startup I work at is getting acquired. Unfortunately management won't (can't?) share anything but vague details. My main concern given the timing is that the valuation will be low and what's left of my equity will be eaten up by investor liquidation preference. Not sure there's much that can be done at this point, but I'm interested to get people's advice, both for what I can do now and for what I could have done earlier.
Will companies tell you what stock is actually worth at different valuations when you join? This seems like far more valuable information than the valuation as of the last round.
Can you negotiate with the acquirer for a retention plan? Unfortunately, as an individual the power balance is very much not in my favor. Has anything like a pop-up union ever been used to get a seat at the table on behalf of the employees? <comment><USER3> Your stock plan should have the data of the valuation when you signed on, and the most recent valuation. If you use something like Carta, that should all be available to you in the app. Even if you don't use an app, whomever own the stock plan should be able to give you that information.

Your compensation and retention is between you and your boss, whoever that is. You are unlikely to get good results by skipping the management chain and asking the acquirer for special treatment. But you should be able to have professional discussions with your boss about your value, and negotiate from there.

There is little chance that you can get a seat at the table for the actual acquisition. That simply isn't how acquisitions work, not unless you already hold a role where the leadership includes you in strategic discussions.

In short, talk to your boss about all your concerns.

</comment><comment><USER4> Does your contract say anything specific about your stocks? Could try reaching a lawyer or union to see what are your rights.

<comment><AUTHOR> I do have a contract with many pages of legal details covering definitions and contingencies, but not what I'm really interested in which is, what do I get at valuation $X.

<comment><USER5> Based on the $, I guess you are in the US, but in which state is your company registered? Every state has different laws that protect minority shareholders. Often, as minority shareholder, you are protected by law and you rarely have to sell your shares, if you don't want to. BUT as the legal system goes - <USER2> it is very complex in the US - there are more exceptions and loopholes than there are rules. You need to know your share agreement and all provisions as well as your state's law. Depending on the state and the form of the acquisition, certain states like Delaware and Texas allow it that minority shareholders can be forced out of the company ([https://smallbusiness.chron.com/force-shareholder-sell- stock...](https://smallbusiness.chron.com/force-shareholder-sell- stock-66789.html)).

Normally, you should first talk to the majority shareholders. Then talk to management, because they only act on behalf of the majority shareholder (I assume they are the same in your case). You could mention that it is your right to know. If they are still not transparent, try talking to a lawyer or somebody that you know has a similar contract in the same state and industry as you.

FYI: I am not a lawyer and this is no legal advice :)

</comment></comment></comment><comment><USER6> Stupid question but what does IC mean?

<comment><USER7> Individual contributor

<comment><USER6> Thanks</comment></comment></comment>


Thirteen Years of Bad Game Code - <AUTHOR> http://etodd.io/2017/03/29/thirteen-years-of-bad-game-code/ <comment><USER2> I tell all the junior Devs: if you aren't horrified by something you wrote a year ago, you aren't learning fast enough. 20 years in and I still find things I wrote 8 months ago that I would not do again.

<comment><USER3> I disagree, if you consistently think that the code you wrote a year ago is shit then you are probably just chasing a new fad every year. I'd say that if a junior developer with a year in a language doesn't write code he can rightfully be proud of then he is focusing on the wrong things.

<comment><USER4> thank you, I say the same thing every time I see this come up.

That's a young mans game, after you've been doing this stuff long enough the things you learn are in terms of systems design, maintenance, etc. I regularly go back to code I wrote 2 and 3 years ago and think to myself "knowing what I know now, that code is mostly alright".

I can't understand how someone can go back and look at some authentication code, for example, and think the way they did it was horrible. Just how many different ways can you write auth code?

It's one thing if you're a young developer, but at some point the improvements to your code are negligible and have nothing to do with the value you bring to a project.

<comment><USER5> Where do you guys get a job without any time constraints? Also were you born with all knowledge? You are saying for example that the booking system you made in 2009, which was the first time you ever "programmed time" is pretty much perfect? (change the example to shaders, or physics, or your first Node back end blah blah). I am calling Bullshit.

<comment><USER4> I would think the ones who constantly go back and worry about old code are the ones you would accuse of having no time constraints.

The thing is, if you're going back to the first time you've ever "programmed time", then what you're assessing is design, not code, which falls in line with what I said.

</comment></comment></comment></comment></comment><comment><USER6> He basically admits that several of the "improvements" boils down to ripping out patterns that decouple code instead of finding alternate solutions. They're kinda quick and dirty, not agile, and could make refactoring a nightmare. I mean, he's not necessarily wrong, but hindsight is 20/20 and once you're done you can look back and cherry-pick and say "ahh, well obviously these things would always need to be coupled! I shouldn't have done the gymnastics to decouple them!" .. but that's a dangerous mindset to start solving the problem with.

The whole topic of global state is very interesting and one I approach cautiously. I'd love to hear what more experienced programmers have to saw. When I go with global state I usually rely on someone else's judgement and use a framework. Like OpenGL and the graphics pipeline has global state.. and I'm okay with that. I use Cinder/Arduino, those things have some global states and for good reasons as well.

But you really try your best to find a stateless solution - and here is feels like he isn't really trying

<comment><USER7> _The whole topic of global state is very interesting and one I approach cautiously. I 'd love to hear what more experienced programmers have to saw._

1\. Quake 3 relied heavily on global state. It was good design, and the engine produced billions in revenue.

2\. Emacs relies heavily on global state. A global variable is a first-class citizen. When a package declares a global variable, it's a contract between the package author and the user that "You may configure the behavior of this package by binding this variable to a new value, then invoking one of my functions." Emacs lisp has language constructs which makes this easier: `(let* ((foo-state 42)) (foo-bar))` will update the global variable `foo-state` to 42, call the global function `foo-bar`, and ensures that `foo-state` is returned to its previous value even if an error occurs and an exception is propagated. In other words, global variables are the interface to a module, just like a module's functions, and global variables are almost never left in an unexpected or invalid state due to errors.

This system works shockingly well in practice. Emacs is basically a gigantic state simulation, and it parallels a game engine quite strongly.

The Emacs Lisp language itself is cumbersome, which has led many to dismiss it as ancient. The true power of emacs has little to do with lisp and almost everything to do with excellent design decisions.

3\. The history of programming informs us that those who hold to dogma are quickly made obsolete. Every tool and pattern has its place. A technique that simplifies X in a certain domain will make X far more complicated in a different domain. Context matters.

<comment><USER8> > _The true power of emacs has little to do with lisp and almost everything to > do with excellent design decisions._

Those design decisions didn't come out of the vacuum. The ability to patch and modify almost everything at runtime is something that came out of Lisp and Smalltalk, and wasn't even on the map of the (currently) mainstream languages until very recently. Dynamic scoping is something that AFAIK has strong Lisp roots too.

Emacs Lisp is less of an accident and more of an old, _old_ language. Even Lisp family moved on to default to lexical scoping, though it didn't remove dynamic scoping - as in many cases, it's still extremely convenient.

<comment><USER9> Dynamic scoping can easily be included when desired in the form of a key-value store. I can't think of any advantage to having it built into the language itself. I guess you could argue standardization, but most modern languages provide a standard kvstore.

</comment></comment></comment></comment><comment><USER10> I wish people would blog more like this.

Majority of blogging is focused on how to use something or describe some final idea/conclusion. They are not bad per se but reading about failed ideas, dead ends etc. - the journey itself that lead to the final shape/conclusion is very valuable.

</comment><comment><USER11> I think I overused every single pattern, method, or framework I happened to learn until maybe after 15 years of coding.

Probably still do to some extent.

Nice read, and something to reflect upon for all young "fundamentalist". It takes some experience to learn when to bend the rules...

<comment><USER12> If you think of patterns and frameworks as tools, when you're a beginner the only way to master and ultimately discover the limitations of those tools is to use them everyday.

<comment><USER13> However you shouldn't release a training prototype. Artists do not release sketches. Architects do not sell concept drawings.

<comment><USER14> Actually artists do both of those things.

And some artists even specialize in sketches and concept drawings.

<comment><USER15> Sometimes professional graphic designers end up selling one of their concept pieces to a customer with a request of "no changes". Sometimes it's even the one the designer least liked and produced as number six of the minimum four concepts just to show the customer more options.

</comment></comment></comment></comment></comment><comment><USER16> Meh. If your code works, then it's good.

Of course I don't literally mean that; you can write code in a way that makes it easier to debug, extend, etc. But too many developers get wrapped up in engineering the perfect system and forget that they're supposed to be, you know, writing a program. I think this is why a lot of hobbyist projects run out of steam.

<comment><USER17> One of the quotes from a senior engineer that has stuck with me over the years:

> "Working is the lowest bar of quality."

<comment><USER15> If you replace "bar" with "rung" I think you may evaluate that a bit differently. According to Kent Beck, "Make it work, make it right, make it fast."

Something that's reached for the most proper implementation, the fastest execution, and the most compatibility with something else is still useless if it produces the wrong results quickly and prettily.

</comment></comment></comment><comment><USER18> I might be biased as I agree 100% on the takeaway, but this is amazing! Not only did he use best practice, but most importantly he made his own conclusions, and learned new things, instead of just accepting things how they where.

When I started coding, I though you could only have one letter variables, like a, b, c, x, y, z. I did not question this, but one day I ran out of variables ...

Edit:

I looked at some of his other posts and saw an altitude bed on an old photo, witch concludes he probably is/was an athlete. I think it's common among athletes to have the mindset that they want to keep improving their skill level. This can be a good trait as a developer, but they are hard to manage, as such persons will quickly outperform their colleges and get bored. They work best with other people like themselves, or with old experienced developers. Make sure you protect him so that he do not burn out himself or his team. While these "10X" developers can work very hard, they are just humans.

<comment><USER19> I started development on Texas Instrument calculators. On most of those, you could only have one letter variables in its TI-BASIC programming. I lucked out and convinced my parents to spring a little extra for the TI-85, and it had a lot of extra goodies, including named variables.

I credit a lot of my initial understanding of how programming works to making various text-based games on those calculators while only half paying attention to class in high school.

<comment><USER20> The TI-85/6 is a magical device. A widespread built-in text editor, compiler and GUI library in one.

I was very sad when I realized the BASIC performance was like an order of magnitude worse than ASM performance.

</comment></comment></comment><comment><USER21> > I was thirteen

No need to be harsh on yourself if you created games like this on that age!

<comment><USER22> Agreed! While a lot of these games might not have been the most pretty to look at or play, I'm sure the author learned a lot making each.

</comment></comment><comment><USER23> I've been running a browser-based MMORPG for a couple of years and when I started out I was a total novice in Node.js. I didn't even know how modules worked so the back end was just one big file. Needless to say, the code is a complete mess and the refactoring has made it even worse since I've started to implement some patterns just to regret it.

I'm thinking of making the whole game open source but I'm so ashamed of the codebase that I don't want anyone to see it. It's a dilemma since I think the game has potential as an open source project. It's inspired by Ultima Online, Minecraft and Reign of Kings but with a lot of constraints making it easy to implement new features. It also has quite a few dedicated players.

<comment><USER24> Don't let us hanging, what's the game? I've been looking for something web- based and casual to log few times a day and click some stuff:)

<comment><USER23> It's actually almost unplayable right now since a bug I haven't managed to pinpoint is messing up all the mines (ugly codebase doesn't help). They're completely strip-mined and the economy is broken with a few players sitting on all the resources. I wouldn't recommend starting until I've managed to fix it in and restart the world.

I'm currently in the process of rewriting the front-end from the old jQuery mess to React. It's like 95% feature complete but as soon as that is done I will start investigating what's going on with the mines.

Anyway, here it is: [http://canvaslegacy.com/](http://canvaslegacy.com/)

Again, I strongly advise against starting right now since you won't experience the game like it's supposed to be. It's hard mode even for seasoned players. :)

<comment><USER25> > It's actually almost unplayable right now since a bug I haven't managed to > pinpoint is messing up all the mines ... > I'm currently in the process of > rewriting the front-end

These two things seem somewhat at odds with each other. Clearly, to players of your game, a fix for this show-stopping bug would offer a fair amount of value, whereas rewriting the frontend, from your description at least, sounds like an exercise that is more for you as the developer.

I'm not criticising, by the way. Just sharing my thoughts based on your comment :)

<comment><USER23> Yes, you are right. The thing is though that I'm making the game mostly for myself and I always tell my players that they are playing at their own risk. It's very early alpha and they may lose everything.

I tried fixing it initially but eventually gave up and put the whole development on hold for 6 months. Also note that the problem gradually got worse. In the beginning it wasn't such a big deal but eventually became post- apocalyptic when players had a hard time finding even the most basic resources.

Another aspect is the amount of support I had to take care of when the player base was at its peak. It almost made me burn out, consdering that it's a side- project that I'm not making any money of. So when this major bug started affecting the game and the active players began dropping it was almost a relief. I never expected that anyone wanted to play it to begin with. I just put it out there as soon as I had something playable.

So after a long hiatus the joy of rewriting the front-end made me motivated to work on it again. Perhaps not the best strategic move but it feels good to be back. :)

<comment><USER25> Great response, thank you for taking my words in the spirit they were intended :) I battle hard to find approaches to my next features that will motivate me to actually get them finished too. I'm learning that this is a big factor in a programmer's experience. So I understand completely.

</comment></comment></comment></comment></comment></comment><comment><USER26> > There are many, many more embarrassing mistakes to discuss. I discovered > another "creative" method to avoid globals. For some time I was obsessed > with closures. I designed an "entity" "component" "system" that was anything > but. I tried to multithread a voxel engine by sprinkling locks everywhere.

Dear God, I feel like I'm having my game dev life read back to me...

</comment><comment><USER27> Made me wish I had more of my old code to cringe at, but honestly I cringe after just a few weeks removed from a project.

</comment><comment><USER28> For booleans prefer prefixes such as: has, can, is. e.g: hasEnemies.

<comment><USER29> isActive

<comment><USER8> In my games now, it's activep ;).

</comment></comment></comment><comment><USER8> I have a very similar history (though a lot worse games). I still have the backups of my first OpenGL programs and game code from ~16 years ago, I might put up a similar article at some point. The difference is that the author's game seem to improve visually over the years; mine actually regressed from 3D to 2D world (since the latter is easier to manage) ;).

Some random comments follow.

> _Still, I loved data binding so much that I built the entire game on top of > it. I broke down objects into components and bound their properties > together. Things quickly got out of hand._

Boy, you have to see JavaFX. And I inherited a codebase at work written by a cow-orker who was absolutely in love with bindings at that moment...

Also the big blob of code reminded me why good macros in a language (not C-like macros) are a blessing ;).

> _Separate behavior and state._

Yeah, learned that same lesson too. I prefer to think in systems operating on data as opposed to a web of objects calling each other. One of the reason is that the web of objects is very implicit; you soon have no idea who actually refers to who anymore.

> _If I start typing self. in an IDE, these functions will not show up next to > each other in the autocomplete menu._

That's a good and _practical_ point, though I feel dirty about renaming functions for solely that reason. I wonder if this isn't time to experiment with some "first-class editor semantics". Here, ability to explicitly mark functions as grouped together solely for the purpose of IDE displaying them like that in autocomplete and outline view. In my evening Lisping, I'd love to have more control over indentation for macros I write.

> _global variables are Bad™_

Yeah, that's almost like "goto considered harmful", and about as much correct as a soundbite (i.e. not very). Unfortunately, everyone keeps writing how global variables are evil, and what I'd love to read is some treatment on how to use global variables correctly. For the situations where - like often in games - you absolutely, positively _need_ a lot of globally accessible data.

> _Group interdependent code together into cohesive systems to minimize these > invisible dependencies. A good way to enforce this is to throw everything > related to a system onto its own thread, and force the rest of the code to > communicate with it via messaging._

That's a... very self-conscious approach. Odysseus-tied-to-a-mast style.

<comment><USER30> Agreed on globals. I learned to code making a huge Java + OpenGL game engine some years back, right when scripted web frameworks were really blowing up and people were becoming test-obsessed. Every new article said that global variables and static anything were a deadly sin, so I did some really ugly things to avoid using them. Now I think global state is significantly simpler for certain systems, better than trying to pass that state around when it'll never be instanced.

</comment></comment><comment><USER31> Well one day I didn't foudn anything better to solve my sync issue with queries to the server than putting a Thread.Sleep(int) the variable name for it was

      private int DO_NOT_TOUCH_THIS_IF_YOU_DONT_KNOW_WHAT_YOU_ARE_DOING_Timeout = 7000;

The code actually made it and is still in production

</comment><comment><USER32> > Unfortunately, Sun decided that almost all Java errors must be recoverable, > which results in lazy error handling like the above.

Not quite: Java insists that all (checked) Exceptions be handled or passed up explicitly. One can argue that this design decision is bad, as has been done extensively elsewhere.

However, in the particular example given, I'd argue that it would have made much more sense to display a user-understandable error message to the user (e.g. "Required gun resource file is missing, please re-download the game here: (...)"), and then just System.exit() if it's non-recoverable. Maybe print a stacktrace if the game was started in debug mode.

</comment><comment><USER33> I really enjoyed this read. I still look at code I write every year and cringe.

Everything becomes influenced by the flavour of the week.

Don't be so hard on yourself, We all suck in hindsight, but its all about recognising it an constant improvement.

</comment><comment><USER34> One mistake you're still making: cross platform. I'd love to try out Lemma on Linux :)

</comment><comment><USER35> > _Unregistered HyperCam 2_

This is legit af

<comment><USER35> > _www.fraps.com_

yesssss

<comment><USER35> Real comment: this advice is excellent, don't fall into the trap of perfecting your tools before starting. The article presents the code quality issues as constantly there and always getting more regrettable over time, but the finished products get better and better!

I say, write bad code if it will get you closer to your goal (here, making a game people will pay money to play). Learn from your mistakes, and make new mistakes next time.

</comment></comment></comment><comment><USER36> As a 2nd semester cs student, that was pretty helpful. I have to design a battleship game in Java and have no idea what I'm doing actually. I'm just staring at the cursor and don't even know where to start, and it's comforting to know that other people struggled as well

<comment><USER8> Battleships? Like that?

[http://static.kidspot.com.au/cm_assets/32032/battleship- game...](http://static.kidspot.com.au/cm_assets/32032/battleship-game-main- jpg-20151022131744.jpg~q75,dx720y-u0r1g0,c--.jpg)

I.e. turn-based and probably doable with an UI toolkit (as opposed to drawing stuff directly with DirectX / OpenGL)?

Anyway, shoot me an e-mail (address in my profile), I'll give you a few quick hints to get you started.

</comment></comment><comment><USER37> Haha, this is great! Memories. All those terrible lines of code I wrote when younger led up to less terrible later. I too got on some of the cargo cults until the harsh reality of the projects showed me why not. :)

This year marks 20 years since opening up QBasic as a 13 y/o.

</comment><comment><USER38> The only way to not make any mistakes, is to do nothing. As Nike says: Just Do It!

</comment><comment><USER39> This `for` loop looks particularly curious to me:

      for (int i = this.bindings.Count - 1; i >= 0; i = Math.Min(this.bindings.Count - 1, i - 1))

Why isn't the last expression a normal i--?

<comment><AUTHOR> Because bindings[10] might have triggered a process that removes bindings 7-9, causing "i" to be out of bounds of the array. I wanted to continue updating the remaining bindings even if some of them got removed.

<comment><USER39> Wow, that's pretty subtle. Thanks for explaining.

</comment></comment></comment><comment><USER40> I want to start writing something that would have been on the original atari to begin with, just have to look like that style. and keep moving up a generation in terms of gameplay.

<comment><USER41> Pico-8 is a good place to start.

</comment></comment><comment><USER42> i would love to read a follow up that dove into the PHP dark ages. i was doing PHP around that time as well.

</comment><comment><USER43> I think we have all been guilty of negatively-named booleans at some point or other.

</comment><comment><USER44> A good retrospective. I'm always inspired by Evan's passion and ability.</comment>


The Most Epic Narrative of Ramayana on the Internet - <AUTHOR> http://beautifulpixels.com/web/the-most-epic-narrative-of-ramayana-on-the-internet/ <comment><USER2> Asking for email for a site which doesn't need it? Instant turn-off. I persevered because I found it intriguing.

I wasn't familiar with Indonesian Ramayana, and thought how could they get the names of major characters and facts wrong(Shinta is Sita here, avlenka is lanka, ayoda is ayodhya, rahwana is ravana, and so and on). But a quick trip to Wikpedia says Indonesia has its own interpretation.

That said, though the concept is intriguing, I don't think html5/js/css is an appropriate medium for this type of interactive storytelling yet. Say what you will about flash, it's a far better medium for this kind of interactive storytelling.

</comment><comment><USER3> Unfortunately they seemed to start with the question "how can we use Chrome and Google products" rather than how can we best present the story. Understandable based on Google's funding of the project. E.g. Do you really need linking in separate windows when you could have used divs? Beautiful illustrations though.

</comment><comment><USER4> I'm not interested in signing up to check it out. No need though as there is a quick high level overview here: <http://www.f-i.com/google/ramayana/>

</comment><comment><USER5> I wonder, why do they ask for an email to read a website? And likely tell me, that I need to install Chrome also.

UX-- = <ctrl>w

<comment><USER6> also doesn't accept email in the form 'email@example.com' so I can't flag them. Really annoying.

</comment></comment><comment><USER7> Doesn't work. It opens the narration window and that's it. Using Chromium on Mountain Lion

<comment><USER8> It doesn't seem to work with fullscreen. Hope that helps.

</comment></comment><comment><USER9> Try RC4YL9.

It really is super impressive.

<comment><USER10> I'm just chaining in case that doesn't work for some reason

9jJdYH

<comment><USER11> Thank you.</comment></comment></comment>


Volkswagen and the Blame the Engineer Game - <AUTHOR> http://jacquesmattheij.com/volkswagen-and-the-blame-the-engineer-game <comment><USER3> My personal suspicion goes way beyond VW in this case. Look at it this way. If someone in your domain of expertise would put out a feat, that according to your experience is just so far beyond the state of the art that it seems to realy violate the rules of what you think possible, and you work in a highly competitive field, then your competitive intelligence will be all over it. Every diesel engine R&D center at any auto maker would have inspected, measured, tested and dismantled these engines to the very last detail. And they would all have discovered the simple truth they suspected all along (benchmark cheating through test cycle detection and software manipulation is nothing new in the industry. Automakers have been caught en fined for this at least since 1998). Yet, none of these competitors spoke up about it. Why?

<comment><AUTHOR> You could very well be on to something there, see:

[https://news.ycombinator.com/item?id=10717216](https://news.ycombinator.com/item?id=10717216)

9 Vehicles tested under driving conditions for NOx emissions.

<comment><USER4> Indeed. And it is troubling to see only VW being targetted here, and with extremely high potential fines shown in the media.

If it turns out that other competitors did the same, VW – and even other German companies, due to the hit the brand "Made in Germany" got from this – might be able to sue the US via ISDS for lost sales in hundreds of billions.

<comment><AUTHOR> That's not how it works, what will happen instead is that those other manufacturers will _also_ be hit hard by the US regulatory entities.

<comment><USER4> That does not matter.

The media focus has been solely on VW, despite others doing the same.

This is enough that VW can show to be unfairly targeted, as it's standard market practice.

If VW can show that others did the same, but did not get the same media resonance, then VW can sue for the lost sales based on an estimation of the difference in reputation loss.

Hell, even other companies in Germany have reported lost sales due to the "German engineering = pollution" that US media have pushed recently.

<comment><AUTHOR> > The media focus has been solely on VW, despite others doing the same.

That's because there is evidence about VW.

> This is enough that VW can show to be unfairly targeted, as it's standard > market practice.

No, it really is not.

> If VW can show that others did the same, but did not get the same media > resonance, then VW can sue for the lost sales based on an estimation of the > difference in reputation loss.

It's an interesting theory about how the law could work but unfortunately somewhat detached from what I know about how the law actually works. VW does not get to claim any 'lost sales' directly attributable to their own conduct, regardless of who reported on it and how frequently even if _all_ their competitors did it too. If VW has evidence that other manufacturers cheat as well they're probably more than welcome to present it. (And if they had such evidence they probably would.)

> Hell, even other companies in Germany have reported lost sales due to the > "German engineering = pollution" that US media have pushed recently.

Yes, and VW is to blame for that. Not the US media.

<comment><USER4> The original report that caused this whole thing presented evidence for 9 companies.

9.

VW is not the only one in this whole situation.

<comment><USER5> The report shown that results from the tests did not match the actual usage. It raised questions that those companies most likely are tampering with tests, but nothing incriminating. It was speculated that possibly that the tests were not reliable.

In case of VW, in addition to that report an actual device to fool the tests was discovered.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Saying the compliance department exists to make sure the company adheres to the law is like saying the HR department is there for employees. That is what they say, but in reality it's the other way around: Compliance acts to protect the company against the law. This has clearly failed at WV.

Also the post assumes a big organisation operates as a whole. My experience is that management high up are either competent and evil, or ambitious and ignorant. That mix lends itself to all kinds of random organisational behaviour. I know nothing about WV, but I assume many people knew this but did not think too much of it (everyone cheats), thought it would help their career (hit that target), or wanted their company become the largest car manufacturer in the world.

<comment><USER7> Jesus, that is a cynical way to look at the people who work in an organization. Is any non engineer not evil or amoral in your worldview?

<comment><USER6> Very few people really think of themselves as evil.

But in my worldview most people (including engineers) cheat a little bit and then rationalize it so they don't have to feel bad about themselves. Big corporations and complex economical systems lend themselves very well for rationalizing your part in something evil away, especially for upper management.

Watch this video. It changed my view on the world: [https://www.youtube.com/watch?v=XBmJay_qdNc](https://www.youtube.com/watch?v=XBmJay_qdNc)

p.s. It has been shown that the psychological profile of top-criminals and CEO's are remarkably alike.

<comment><AUTHOR> > But in my worldview most people (including engineers) cheat a little bit and > then rationalize it so they don't have to feel bad about themselves.

So, if we assume that is 100% accurate then maybe a company the size of VW should have a department that checks up on these sneaky cheating engineers to make sure they don't expose the company to liability.

The whole idea is that the company avoids - given the size of the penalties involved - to be caught cheating, especially not at this scale.

Then there is the matter that the ethical rules for engineers specifically state that an engineer will _never_ assist or cause a company they work for to break the law. (For some this sort of an oath may hold more strength than for others, but it must have been very clear to the people involved they were doing this to break the law and they would have definitely wanted at a minimum indemnification from higher ups about the possible consequences of this if they didn't actually blew the whistle internally.)

This is the sort of thing that Germans tend to be big on and it is one of the reasons 'made in Germany' was seen as a source of trust and quality.

VW management is throwing all these values under the bus as if 60 years of brand creation are utterly worthless.

<comment><USER8> I don't know how VW gets audited but in US, when a company is audited by their accounting firm, one of the sections is a "Process Audit" \- checking to make sure that regular business practices are followed.

In a perfect world, audits would catch these things, however, because there is a lot of pressure on accounting firms, usually, this step isn't given a lot of consideration.

In the event a company is caught, the accounting firm takes a hit on their reputation and have to go back, re-audit, and change their designation of company policy.

Source: my wife works at one of the big 4 accounting firms and recently explained how an unrelated company had similar issues in failed business practices etc. etc.

<comment><USER9> Sure, and sometimes these audits are people asking the managers "do you do this?". That is all they do. They don't sit in and watch people.

<comment><USER10> >sometimes these audits are people asking the managers "do you do this?".

I work for one of the large pro services firms that does internal audit, compliance/risk projects, strategy consulting, etc.

I'd argue that unless there are explicit sets of controls that HAVE to be tested as part of the project scope (which is usually defined by regulatory requirements), _most_ audits are just people asking questions and ticking off boxes on a checklist. Most of the bigger firms even staff these projects with fresh graduates that often know absolutely nothing about what they're auditing.

<comment><USER11> Conducting an audit doesn't necessarily mean that you check everything. Often, auditing is looking for evidence as to whether a particular procedure was followed or not.

For example, say you're auditing a large company for compliance against a information security management system under ISO 27001, and you're checking to see whether the organisation you're auditing actually _does_ keep its operating systems patched and its anti-virus software up to date.

You'll certainly ask questions about whether, how and how often the updates are done but you're probably _not_ going to check every single server, desktop and laptop because that would be too expensive. What you'll probably do is check a sample, and if all the devices in the sample are all up to date, you'll tick that box and move on.

If, on the other hand, you find that half the desktops you check _haven 't_ been updated, then that's evidence that the updates policy _isn 't_ being followed, and would trigger further investigation, and probably a failure on that specific audit point.

The equivalvent check in the VW case would be to run a test of the engine's emissions. It's not unreasonable for the methodology used to be based on that used by the regulatory body, in which case, it would have passed the audit.

<comment><USER10> Nothing you're saying is wrong or theoretically unsound. But in practice, 'looking for evidence'-type activities are frequently glossed over, even by very reputable audit firms.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Is it fair to characterize Volkswagen's response as "blame the engineer"?

For example, from [http://www.wsj.com/articles/vw-shares-up-ahead-of- emissions-...](http://www.wsj.com/articles/vw-shares-up-ahead-of-emissions- findings-1449740759)

> Volkswagen has suspended nine managers suspected of being involved in the > fraud

> Volkswagen has replaced six executives since the beginning of the year and > has switched leadership of seven of its dozen brands.

> Volkswagen also disclosed in November that employees had tipped management > off to another unrelated issue, saying the company had understated > greenhouse-gas emissions and fuel consumption on up to 800,000 gasoline- > powered cars. After an internal investigation, Volkswagen lowered that > figure to fewer than 50,000 cars.

<comment><USER13> Categorizing it as "blame the engineer" is sadly accurate in my opinion. That has been VW's stance from the very beginning. VW's US CEO said, while denying a corporate-level scandal, "software engineers who put this in for whatever reason," to a congressional panel back in October: [http://arstechnica.com/tech-policy/2015/10/volkswagen- pulls-...](http://arstechnica.com/tech-policy/2015/10/volkswagen- pulls-2016-diesel-lineup-from-us-market/)

Certainly doesn't get any more "blame the engineer" than that, unless they're supposedly somehow changing their tune now... which is not my impression.

With regards to middle management being laid off, it strikes me more as the C-level players insulating themselves from the taint.

<comment><USER14> At least two of the people fired were C-level engineering managers (chief engineers), and in fact they are the people often cited with hatching this plan in the first place.

I'll keep saying it -- there seems to be some belief that anyone sitting in the boardroom is not an engineer. That may be how you see it, but it's not the common perception.

</comment></comment></comment><comment><USER15> Yes, but in this case compliance is quite difficult. Why would the compliance department go out of its way to develop a new mobile testing infrastructure when that isn't the industry standard? So it seems very plausible in this case that compliance might not have found the issue. It required a novel method of testing to discover the cheat.

I have to be honest, when I first heard about this, I suspected a genetic algorithm as the culprit. It's exactly the kind of result you'd expect when giving an impossible optimization without sufficient boundary constraint. AIs can and have been known to cheat, and because the fitness driver would have been compliance (V&V) the GA could plausibly have settled on methods that were undetectable (i.e. Not part of the fitness function).

Often the output of GA code is not understood formally by engineers, or reverse-engineered into a traditional algorithm, so it's plausible that it could have remained hidden in plain sight.

BUT, if that had truly been the case, the engineers at VW would have quickly suspected and publicized it. So the fact that VW blinked showed that in fact they lied and didn't have an honest technical explanation.

However, I think the GA scenario is good to keep aware of as we increasingly rely on machines to optimize solutions based on testing.

<comment><USER16> The "sin" they are accused of it explicitly detecting that certain test equipment is connected. That's a binary, if-then-else sort of thing. "The boss is looking; look clean."

A GA (or any machine learning ) within a controller is less about being able to cheat than it is ...rebasing something that would otherwise be a constant (from the frame of reference of the algorithm) in a control-feedback arrangement.

If the GA was part of a test stand and exhibited emergent... dishonest behavior :) then ... they did it wrong.

<comment><USER17> There are valid reasons to write code to determine if your vehicle is being tested. Modern cars contain all sorts of computerized safety features that would go active in the typical test scenario thereby preventing the static tests that the EPA and others do.

So the car detects wheels straight, only drive wheels turning, and so on, so it disengages the features that would active traction control, reducing engine power, and more. The key here is that VW engineers went further and used that as they indicator to run the full emissions process and only then. There is no viable reason to have any toggle on emissions processes except perhaps with regards to cold weather starts.

<comment><USER16> We _think_ it's "run the full emissions process" but we're guessing. It's a very good guess, but it's essentially unsupported. It could have been an interaction with one of the other things that got turned of. This seems unlikely,. but it's not 0% probability.

</comment></comment></comment></comment><comment><USER18> >...without the compliance department...

In my experience compliance departments make sure you're compliant within reason. They aren't going to go out of their way to determine if you're cheating unless they've been mandated to due to prior internal or industry incidents. Even in companies where they have to audit controls because of regulatory obligations they're only going to audit what they're required to. If you find a way to outsmart the controls or checks and balances they're not going to notice until you slip up or you're otherwise caught.

>...and all outside verification labs being in cahoots.

Does this have to be true? They would only need to apply the cheating behavior for the lab testing the way they did for regulatory testing.

And VW suspended nine middle managers. I think it's less about blaming the engineers and more about deflecting blame away from senior management.

<comment><USER4> > And VW suspended nine middle managers. I think it's less about blaming the > engineers and more about deflecting blame away from senior management.

Well, they also had two CEOs resign over this, one even refusing to take any golden parachute he might have gotten otherwise.

It's more the board that's scared right now...

<comment><AUTHOR> I suspect it is a matter of time now before someone leaks an email to the press indicating that the previous CEO _did_ know about this (they'll be thrown under the bus), and the board will then try to wash their hands of it.

It's a classic fall-back action, first sacrifice some lieutenants, General admits ignorance but admits to no wrongdoing and is pensioned off.

If the bad weather blows over that's where the story ends. But if it doesn't then sooner or later the eyes will focus on the General again, what he knew and when he knew it and then the inquiry will begin in earnest.

There hasn't been anything surprising in this whole affair to date.

<comment><USER4> Well, the first CEO, who resigned in April, admitted already to personally pushing the whole issue.

It was his personal project (he's been involved with some engineering for quite some time) to use that specific type of engine, which provides mileage of up to 270mpg in real world usage, but produces NOx in amounts that Satan would be jealous of.

So, that's it.

<comment><AUTHOR> Yes, but he did not admit to actual knowledge of the defeat device.

</comment></comment></comment></comment></comment><comment><USER19> Disclaimer: I work for a competitor.

Bottom line: real world use should be tested, but this is expensive and neither side wants to pay for it.

Regarding compliance department complicity, the biggest factor in my mind is two-fold: You test for compliance with regulations and you have limited time. You ensure that the internal test parameters match the external regulatory test. You don't have funding to do real world tests. You don't have funding to do static code analysis. You believe the documents you are given, as they have been signed by responsible adults. You use the tools you are given, because they have been developed by professionals.

Regarding what competitors knew and when: I haven't seen a discussion of exactly how much better these engines were than competitors.

Regarding the scandal in general: The public has been demanding better and better automotive safety and quality represented by government regulations, voting with dollars, and lawsuits. It takes time for these lessons to be internalized, and different corporations and internal groups do this at different speeds. If you are the largest automaker in the world it is kind of natural to think that everything must be ok! (See also: GM, Toyota)

<comment><USER20> I can imagine this as not totally different from software dev and QA. Many times the development team puts in some feature that doesn't have any visible output for the testers to test - rather it is some internal change or improvement.

The QA department, then responsible for testing this new "feature" will most likely go off of a script that was sent to them by the developers to verify the old and new behavior, going on some metric that perhaps they don't really understand.

In some cases, the QA may actually have to rely on a tool actually built by the developers to test the feature. So in some cases the QA, not being software developers and not responsible for actually reviewing the code, will have to somewhat go on faith that the scripts and tools provided by the developers are accurate.

I'm not saying that means the engineers were responsible at VW, but it does explain how something could slip through the checks-and-balances that have been set up.

<comment><AUTHOR> > The QA department, then responsible for testing this new "feature" will most > likely go off of a script that was sent to them by the developers to verify > the old and new behavior, going on some metric that perhaps they don't > really understand.

That's wrong right there. If you do this properly the people writing the QA test script work from the same _spec_ the programmers used to implement the feature but they are actually different people and the test gets written first.

Obviously in smaller shops that won't work but anything the size of newsworthy should be set up like that.

<comment><USER20> I definitely agree that's the way it _should_ be. I've seen the reality inside a few large corporations and basically nothing would surprise me.

</comment></comment></comment></comment><comment><USER21> The funny thing is that the engineers that wrote the code don't actually work at VW. If I am not mistaken, their engine control sytems for their Diesel engines come from Bosch.

Also, if you talk to an engineer you will quickly hear that there is a connection between fuel efficiency, power, and emmissions. If you drive the engine with parameters tuned for low emissions, you'll get less efficiency etc.

But the engineers don't seem to care that the engine stats claimed by VW are not actually possible...

<comment><USER22> > If you drive the engine with parameters tuned for low emissions, you'll get > less efficiency etc.

Can you explain that further? Given a specific power output, lower emission levels would to me indicate that the engine is doing more with a smaller amount of fuel, indicating better efficiency.

<comment><USER23> Your argument mainly applies to CO2. Generally, Diesel engine reach better efficiency at higher temperatures, but higher temperatures also lead to more NOX being created. So in the case of NOX, it really is a trade-off.

<comment><USER24> Unless you use ammonia (from heated urea solution) in a catalyzed reaction, to react with the NOx to produce N2 and H2O. In that case, the trade-off is that you need to add a separate urea tank to your vehicle, and distribution infrastructure at all diesel fueling stations.

</comment></comment></comment></comment><comment><USER14> I think there's a perception problem here. What the press and VW management has said is that this project was knowingly commissioned by VW's chief engineer. Yes, this guy's title is "chief engineer," and he has the bona fides to prove it, but you should focus on the "Chief" part -- he's a C-level executive whose day to day activities and demeanor would be indistinguishable from a CFO or CEO.

There's this reflexive reaction on Hacker News that has come up again and again of, "don't blame the engineers, they are just the nerds in the basement hacking the code, some evil management type put them up to it."

What we know so far is that the evil management type who put them up to it -- was an engineer. The chief engineer in fact. So, in fact, it's highly likely that "the engineers" designed and implemented this entire scheme without telling anyone else. In my mind, that's an entirely plausible explanation.

I'm not an expert on VW corporate structure, but it's entirely possible that the Compliance/Quality departments report into the Chief Engineer. They do at other companies where I have worked. If that's the case, then they could have been in on the job and it wouldn't have changed the fact that "Engineering" was responsible for this implementation.

<comment><USER25> I don't think a blame group size of 10 (the number thrown around by VW execs) denotes a systematic problem, which you would expect with a C-level executive being called out. That's a ridiculously small chain for a company of VW's size.

</comment></comment><comment><USER26> Here's the question that you need to ask yourself: The cheating that VW did allowed them get an emissions score that is an order of magnitude lower than the truth. Now, if everyone else was being honest, either A) their performance would be an order of magnitude lower than VW's, or B) everyone else has discovered magical technology that VW lacks. Neither of those things is happening. The conclusion is obvious: _everybody is cheating, and they always have been._ I mean, a hack of this magnitude wouldn't be performed without management approval from top to bottom, and let's face it, the only way management would have the balls to do something like this is if it were industry standard practice.

<comment><AUTHOR> That's not the whole menu of choices. The other option on the menu is: VW found that cheating software was cheaper than actually doing something about emissions. The other manufacturers are not that much better than VW at engineering they simply threw more money at the problem. VW tried to do an end-run around both solving the problem _and_ passing the tests.

Another reason why VW has the spotlight on them is because they are the largest player. If VW were given a free pass and a lesser manufacturer would be taken to the cleaners it would be a different situation altogether. I think there will be more manufacturers that will have to own up to 'gaming the tests', maybe even some that actually have a similar device but the majority of the cars are not nearly within the range of test:regular that that particular engine is. 40:1 is a bit more than an oversight or a small error.

<comment><USER26> You're right, that is possible. But given that VW is the largest player, why would they be the one to throw less money at the problem than anyone else? But VW being the largest is a good reason to make an example of them.

<comment><AUTHOR> I suspect because of timing. If they had not been fully invested in that particular engine at the time they would have had a way out. But given that they already had made a commitment the choice was to drop the US market for their small diesels or to cheat and they - unfortunately - chose the latter. It was both cheaper and the only solution that worked under time pressure. Someone probably thought they were very clever when they thought of this.

</comment></comment></comment></comment><comment><USER27> I would blame an engineer, but those who designed and ran emission tests.

US suddenly discovers that a few million imported cars do not meet their requirements, despite passing all tests and paperwork. Good way to collect a few billions on fines and damage competition.

If EU would enforce their laws on US products similar way, there would be an economical war.

<comment><USER28> The regulations require certain levels of emissions to be met under all conditions. The tests exist to verify compliance, but the regulations don't merely require passing the tests. When you optimize solely for the test and lie on your paperwork, you shouldn't be surprised when you get smacked down. I strongly doubt that if a US company did this and got smacked down by the EU that any "economical war" would ensue.

</comment></comment><comment><USER29> I am not fully convinced by the compliance argument.

People from other industries, for example the financial, have written very candidly on how easy it is to side step and circumvent the rules leaving their compliance departments in the wishful dark.

<comment><USER30> Yes an in-house compliance department, like a private auditing firm, leads inexorably to agency problems. They don't work for the general public or for investors; they work for the management of the firm. Generally it's best to just live with these agency problems, since we don't want to shut down corporations entirely, but in cases like this the government might need to do more.

</comment></comment><comment><USER31> I don't buy this from VW for a second. I am not sure what the work environment is in Europe but in all the corporate places I have written code for in US if I pulled a stunt like this with no backing from managers the best I could hope for is getting yelled at. Most places would have fired me on the spot. The possibility of this being a rogue engineer is extremely remote. This screams management cover-up.

</comment><comment><USER32> > _compliance department_...

Right. You know who else has compliance departments? Financial institutions. Did any of those prevent or foresee or had any clue at all about the financial crisis? Nope.

You know why? Because compliance departments don't have teeth.

In an ideal world, compliance departments should be staffed with asshole anal geniuses.

In reality, they are staffed with dopes and yes-men.

They shuffle papers and cover themselves, asking questions such as "are you following rule A and B as stated above"? and all you need to do to get them of your back is answer "yes".

They never have any further question because they're not sure about what the regulation actually says and they fear you'll find out if they start to dig deeper.

<comment><USER33> > You know why? Because compliance departments don't have teeth.

Unless they do of course.

> In an ideal world, compliance departments should be staffed with asshole > anal geniuses.

That's the (legendary) IBM Black Team option. That's not the only one though, the (almost as legendary) "on-board shuttle group" did that with friendly rivalry and an absolutely anal _process_ (which, importantly, is _solely_ blamed and amended whenever problems occur).

</comment></comment><comment><USER34> I spent a large part of my career in the global automotive arena supplying products to VW. Martin Winterkorn was a frequently in attendance at meetings where technical proposals were presented for consideration. He typically led the way in asking tough questions related to form, fit, and function. VW invested billions and bet the future of the Company on clean diesel technology and performance. Martin Winterkorn is hands- on to the point of being a control freak, and it's impossible to believe that he didn't exert influence to bend the rules.

<comment><USER35> Interesting. At this point, I think the VW executives are trying to avoid going to jail. They will say almost anything to bend and distort the truth.

<comment><AUTHOR> Yes, that is my impression as well. That's why they've decided VW as a brand can be thrown under the bus as well as long as they get away with this. But it is getting so large now that I doubt this strategy is going to work they are clearly reaching for straws to be able to claim plausible deniability.

</comment></comment></comment><comment><USER36> I work at a place exactly like this.

They give you 2-3x the work you can complete, then tell you "you get paid the big bucks" (which we don't) so you need to work as many hours as necessary to get it done. Oh, and don't get behind on any of your other work as well.

It's why my last day is coming in the next week or so.

</comment><comment><USER3> Having worked in highly regulated environments, I would characterize the role of the compliance department more as enabling business operation and development while keeping the regulatory risks acceptable. Often times I found out technical staff had a far more black & white view on rules and regulation than was warranted by compliance.

<comment><USER37> Ditto. I would add that Compliance only really works when they are given accurate information.

If the engineers asks "is it OK if we do X" and Compliance says "No" but engineering goes ahead anyway, that will likely be the end of it unless something bad happens. The reality is that a lot of questions & answers end up not being documented so even an internal audit later won't discover them.

</comment></comment><comment><USER38> What bothers me is they fail the reguntaltions for such a high margin that i cant belive all other auto makers complay with them. I mean, can X be 400% better than VW. Are their engineers 400% better? This is atonishing at least, hardly belivable. There is no such a difference with the state of the art in any industry.

<comment><USER33> Other manufacturers don't have 400% better engineers, the difference is _other manufacturers didn 't globally bet on diesel_.

The US has very, very stringent NOx regulations, much more so than Europe (VW's cheating was in fact discovered through european clean diesel advocates pushing for tighter US-style regulations): EPA Tier 2 / Bin 5 has a 0.043g/km limit whereas EURO5 is 0.18g/km and the new (2014) EURO6 standard lowers that to 0.08g/km (still twice EPA)[0].

Diesel has plenty of advantages but is a big producer of NOx (compared to gasoline) because NOx is formed at high pressures and temperatures, and gasoline engines have much, much lower pressure and temperatures than diesel[1]. Also importantly, increasing diesel engine efficiency runs them hotter, which increases NOx production.

VW bet on a all-diesel strategy worldwide, and that included a "clean diesel" push in the US.

[0] for what it's worth, VW engines don't pass EURO5 either (in fact they don't even pass EURO3, the first EURO standard including NOx) which is why they're _also_ in the shit EU-side, just to a way lower extent than in the US (their engines exceed EURO5 limits by a single-digit factor versus double- digit for EPA limits)

[1] EURO standards reflect this (though whether they should is debatable), EURO5 has a 0.18g/km NOx limit on diesel engines but 0.060 on gasoline

<comment><USER38> Thanks for your explanation. But i think the problem here is not the strategy. We are talking about individual car performance. This is not about the NOx produced by the whole VW cars. Every other single manufacturer car is at least 4000% better ? Incredible. This is the question.

<comment><USER33> > But i think the problem here is not the strategy.

The problem _is_ the strategy.

> We are talking about individual car performance. This is not about the NOx > produced by the whole VW cars.

We are talking about the NOx emissions of diesel engines in general, and of VW's decision to base their US and global strategy around diesel.

> Every other single manufacturer car is at least 4000% better ? Incredible. > This is the question.

What's the point of praising my comment if you didn't fucking read it? Other manufacturers don't have 4000% better cars, in the US other manufacturers _sell gasoline cars which intrinsically produce significantly less NOx_.

<comment><USER38> No other auto maker sells diesel in us? Is VW the lonely seller? I read your comment, it seems you not. Or VW is the lonely seller and you are right :) Anyway drawk has a point on this

</comment></comment></comment></comment></comment><comment><USER39> If the design requirements state: "engine must meet emissions during test" and the tests show this to be the case, how do the compliance department argue otherwise?

<comment><USER40> The compliance departement is supposed to test independantly for exactly the same reason you software testers should actually test the product and not just believe the software engineer when he says: "it works".

</comment></comment><comment><USER41> I just want to say, as an Engineer this is why you don't willingly break the law for a company. I had a job where I stayed for less then 3 months because they wanted me to use the community version of Visual Studio. Except it broke the terms of service and I could be liable if they tried the "blame the engineer game." Otherwise it was a great company that was doing innovative and fun things. They just wanted me to break the law, and I said no.

P.S. This was innocent on the companies part, they thought it was OK and didn't read the TOS, when I brought this to their attention they entered "talks" with Microsoft to get a new set of licenses, I just wasn't willing to accommodate them in the short term. I also didn't know what the talks were so I had to cover my butt and get out.

<comment> UK-AL It's ok to use to the Community edition if your company is under a certain size, revenue etc

<comment><USER41> Part of what I did was point that they didn't fall into that category out to them. And that because of that they couldn't use Community edition for anyone.

</comment></comment></comment><comment><USER42> Why are so few people questioning the regulators, too? I cannot conceive that it is that easy to fool them.

<comment><AUTHOR> The testing capabilities of government labs are handily outstripped by industry capability to create differentiated products. The cost burden of regulation testing is to some extent pushed back to the manufacturers with a big 'comply or else' warning to make sure they take it serious. The 'or else' bit translates into a fine per product sold which means if you get caught cheating that will eat up a very large chunk of your turnover for that market making getting caught something you will want to avoid so much that compliance is the easier way out. And if you can't be compliant then the better idea is probably not to try to sell your products into that market.

<comment><USER14> This. Almost all regulatory bodies, whether CARB, OSHA, EPA, USDA have been pushed into a mode of "self-certification", where the regulated effectively police themselves. Compliance bodies rarely have the staff or the budget to audit more than a scant fraction of the test results that are submitted to them.

For this to work, the punishment, when caught, has to overwhelm the profit from the deception by not just a little, but by a large multiple. Otherwise, companies will realize that they can just take the risk and will only have to pay up in the unlikely case that they are unmasked.

</comment></comment></comment><comment><USER43> It doesn't even matter if it was the engineers, the fact that management is not taking the blame itself is utterly despicable. I'm certain the claims of this article are true, but let's pretend it was a bunch of rogue engineers' and compliance people's conspiracy. It is the responsibility of the company to take responsibility for ALL actions of ALL employees, whether they were known at the time or not. That's the whole point of being an executive. That's the whole point also for people who are not executives. Most engineers could start their own firms but choose to work for others for a number of reasons, not the least of which is minimizing risk. One of the major risks that one minimizes through employment is that of being sued or holding blame in _exactly a situation like this._

VW knows this, yet they're still trying to make it seem like this wasn't the fault of their upper management and executives. They're still trying to shirk the blame when they should be firing their whole upper management employees and executives. There is no excuse for not doing that, and the CEO quitting is not enough in this case. To blame it on engineer and compliance workers is absolutely despicable and irresponsible.

<comment><USER14> What do you mean that "management" is not taking the blame? The CEO resigned. The two chief engineers who reportedly hatched the scheme (who are as upper management as you get, they reported to the CEO) were fired. The head of US operations was also fired.

What more are you expecting? And how does this make it sound like it's not the fault of upper management and executives?

</comment></comment><comment><USER44> This is exactly what happened with Enron and the backlash against that level of cheating -- the Sarbanes-Oxley Act.

I refuse any argument that a line-level IT staff member cooked the books there on their own, yet the response - draconian controls placed on access to production data - does nothing to stop that from happening again.

All it did was make maintaining IT systems far, far more difficult to the pool on call schlep who has to delete a bad file at 3 in the morning when they have to involve 6 different people and levels and levels of approval (which takes until 10am to do). SOX and its ilk does nothing to stop unscrupulous top-level execs from hiding things.

</comment><comment><USER45> The Automotive engineering culture is very much an optimising one - <USER2> squeezing to reduce R&D lead times and engineering costs to somewhere just below the bare minimum. This works fine when it is balanced by objective measures of quality, so you know when the job is done and when you are being lied to, but as complexity increases, so the risk of operational ignorance and plain-old self-deception proliferate.

The more complex the system, the greater the reliance upon the integrity and professional ethics of the engineers working on it, and on the correct functioning and sophistication of the checks-and-balances within the organisation.

</comment><comment><USER46> "The only alternative explanation (and one that is even more worrisome) is that the entire compliance department and the entire management of VW were so dangerously incompetent that they allowed a situation like this to come into being, exist for several years and required an outside party to bring to light."

Hanlon's Razor: "Never attribute to malice that which is adequately explained by stupidity."

That being said, it really doesn't matter if it was on purpose or on accident, both indicate a company which should not be able to sell cars in the U.S. There are plenty of other cars to choose from.

</comment><comment><USER47> Of course, they could have fooled the compliance department using the same techniques used to fool regulators in the U.S., i.e. the exact same capability they'd built into the software. And they could probably have managed to trick engineering into creating that capability in the software by labeling it with a different and seemingly legitimate reason for existing. So I think you could plausibly get it down to just upper management, but I agree that there is no way engineers knocked this off by themselves.

</comment><comment><USER48> Never attribute to conspiracy what you can attribute to incompetence.

I work on a software product that's very hard to test. IMO, it's harder to test the product that I work on than to implement the product.

In VW's case, I think it's safer to assume that emissions testing is harder than we realize. The engineers might need to make assumptions that, in practice, require a very complicated test situation to verify.

Therefore, the real problem is playing the blame game.

<comment><AUTHOR> VW is actually stating there is an in-house conspiracy but the top level management didn't know about it.

</comment></comment><comment><USER49> I'm still waiting for the smoking gun of actual code that detects a testing cycle and changes the operational parameters in a way different from the way parameters are adjusted normally for different operating ranges.

Optimizing for test cases is rampant in the car industry. Nobody who has owned a GM car in the OBD II era has ever said "Wow, I get better MPGs than the EPA rating!" Heck, I'd be thrilled if any GM I'd ever owned came close on the highway doing 55 with the cruise control on. One of my GM's had something called Active Fuel Management. Cylinder deactivation. In normal driving it rarely comes on, but when it did there would be an annoying vibration and hum from the exhaust that would make you give the car more throttle in order to make it stop. My real-world MPGs sucked but apparently that anti-feature boosted GM's numbers for MPG and CAFE purposes.

Another GM car I currently own with a manual transmission forces a 1 -> 4 shift if I attempt to shift from 1st below certain throttle position and RPM thresholds. Out on an actual road, even with a giant V8, lugging around in 4th gear at 1,000 RPM is an undesirable condition. Naturally I do my best not to let that happen by applying my foot to the throttle, but somehow, again, this anti-feature improves the government numbers while I average 18MPGs on a mostly highway cruising commute and much less in stop-and-go city driving.

How are these GM anti-features any different from what VW has admitted? In the GM case the cars very obviously are detecting conditions within a test cycle and causing the car to operate in a manner undesirable to the driver, and which will cause the driver to alter their behavior to avoid them.

Is what VW did so blatantly obvious to a driver? What's the legal distinction? Where's the smoking gun code piece of code that makes their actions a "Defeat Device"?

On the premise of this article, the whole automotive testing industry is optimized around testing to the government standards. Just like No Child Left Behind has our teachers "Teaching to the Test", the automotive industry is "Testing to the Test." Nobody has any motivation to care about, or even look at, what happens outside of the test parameters. No grand conspiracy is necessary for this to have gone undetected or ignored. If the government considers this a problem then the solution is to create more tests that better simulate real-world driving conditions.

<comment><AUTHOR> The legal distinction is that the code in the VW ECU actively detects the testing regime and then switches the engine to a mode of operation it would _never_ use during real world conditions.

That's no longer optimizing for a test, that's simply fraud. Other manufacturers performance deviates gradually the further away you get from the test parameters. The VW would _never_ have the performance it has during a test in any real world conditions, not even those matching the test (because the vehicle is moving and it can tell the difference).

<comment><USER49> I see speculation that there exists code that detects the test and activates a special mapping mode. I haven't seen that anyone has actually found the code or map. The map ought to be easy to find, VW ECUs appear to have as many freely-available DIY tuning tools as other platforms.

I've also seen it speculated that the code to detecting testing is based on determining that the car is on a dyno, and that all manufacturers perform that detection in order to disable the stability control systems. If it were as straight-forward as VW switching to a different map on a dyno I'd have expected that VW tuners would have blown the lid on this thing long ago. Tuners use dynos.

</comment></comment></comment><comment><USER50> If an engine does not meet the requirements and because of this, cannot be sold on a market as large as the US or Europe, this is a big thing.

Unthinkable, that this has been measured and not been reported, but instead quickly and silently hacked. Indeed, even with a new head, there is still something wrong at VW.

<comment><AUTHOR> Even more unthinkable that there now is a 'quick fix' that costs very little money per vehicle and will magically make the car meet emissions standards _and_ will not lead to loss of power or increased emissions. If it was that simple you'd think those bad boy engineers would have implemented that right from the get-go rather than to go this somewhat harder route to the goal.

<comment><USER50> By the way, as a reaction to this issue, a german motor magazine has measured real life compliance to the Euro-6 norm for a couple of popular cars: VW Golf, Opel, Audi, Mercedes c-class, Fiat 500 etc. All, and I mean ALL of them emit 2-8 times as much as allowed by Euro 6. The heavier the car, the worse the result. All SUVs like the Audi Q3 or BMW Xx have terrible measurements. The best - was the VW Golf with the 2 litre engine. The worst was the Audi Q3, which emits 5 times as much as the Euro-5 norm (which it was adapted to) and thus 10 times as much as Euro-6. Shame.

<comment><AUTHOR> Link?

<comment><USER50> I was about to write: "there is something like printed journals" (I read it at the physiotherapist while waiting for my treatment). But it is online: [http://www.auto-motor-und-sport.de/testbericht/real- abgastes...](http://www.auto-motor-und-sport.de/testbericht/real-abgastest- wie-sauber-sind-diesel-wirklich-vw-abgasskandal-10254994.html) Test your german.

I just saw, that the Fiat 500 is even worse that all the others. Shocking results.

<comment><USER51> If I understand correctly, _all_ of the cars tested (including the petrol one) exceeded their NOx ratings by at least 60%. Of these, the VW was actually the second best after the petrol one. The older Audi model they tested didn't fair as well, but it still did better than the BMW, Opel, Volvo, or Fiat. Going off of that, it would seem that VWAG was unfairly singled out.

<comment><USER50> "it would seem that VWAG was unfairly singled out"

If you look at the true numbers, yes. But VW has been targeted for intentionally cheating. And don't forget, some Audi engines are also inherited from VW.

</comment></comment></comment></comment></comment></comment></comment><comment><USER52> It's ridiculous, how they've tried to shift blame. But forget compliance departments and everything else, the situation is actually very simple: the company made money on the cars they sold, so the company is responsible for how the cars were built.

</comment><comment><USER3> Another pertinent question for the techies here: how come we have secure boot loaders and signed drivers for tablets locking them down, yet chipping or remapping the cars ECU to negate any 'environmental restrictions' seems to be unrestricted?

</comment><comment><USER53> Does the engines comply with EU standards? Why US Standards are different?

<comment><USER54> Why is US money different? Why are US plugs and voltage standards different?

Sovereign countries have the right to set their own regulations and bureaucrats don't have a strong track record of international collaboration.

<comment><USER55> I would say he was asking for the technical details...

</comment></comment></comment><comment><USER56> Everyone even the engineers deserve blame.

</comment><comment><USER57> "zum kotzen"</comment>