Go to Europe. The low emissions were a major part of their marketing. The fraud goes beyond the EPA most likely, there is evidence of test cheating in Europe now too, and many countries are opening up investigations. Sure, in the US many people here don't give a shit about clean air, but the fraction of VW diesels in the US is tiny. In Europe VW is much bigger and the percentage of diesels is much higher, so this is a much bigger scandal than just the insular United States.
Sure we gain more. We send a big mesasge that no one is too big to fail or too big to be above the law. If a company gets only a slap on the wrist, you can never trust them again to have learned their lesson.
This scandal is going to be huge, and they're going to lose a massive amount of stock price and market share. This is not just an issue with EPA rules and tiny fraction of the US market. VW is so much bigger in Europe, there are so many more diesels sold there, and the market there in general cares a lot more about low emissions than in the US. In the US it may be fraud that can be overlooked because we like powerful cars here, but in EU the fraud won't be brushed off as petty shenanigans. Investigations are opening up around the world and there are hints that this cheating also is going on beyond just the American market. Then going further, there's going to be a huge scandal all over if it turns out the government testers in the EU who were posted inside the auto plants failed to detect these problems (or more likely, failed to report).
Although the summary is misleading, I think there are people very confused about the social aspect of social media. A Facebook friend is not necessarily a friend. Being unfriended does not mean you lost a friend.
Right. But I'm on a brand new product. It doesn't exist yet. There are no customers. The internal requirements being driven from outside of engineering keep fluctuating as they try to identify potential customers and guess what they want. But there's no guarantee that the end goal is even achievable, the parts being relied upon don't do what their marketing claim for example.
Even if it's just a feature added to an existing product, I have seen cases where there is just not enough evidence at the start to indicate whether the feature is even feasible much less how long it will take. Such as, will it fit in the remaining memory or will we have to wait for a next generation hardware platform? That's why it's called R&D - you start with the Research and then later the Development. But there are places that start with the D instead, and only occasionally get around to the R.
But it's been a while since I've worked anywhere where customers were so closely tied to requirements. The releases and products are usually intended for many or all customers. Though I did work at one place a long time ago when every release was used only by one customer, and everything felt random and support was a nightmare. Never want to go back to that sort of environment.
Yes all that stuff too. I was the C++ "expert" at one company, meaning the one who translated the obscure gcc error messages, and who kept the runtime working. And Boost was difficult to maintain at times.
I think people that are good at estimates are doing the same things over and over. Such as adding a small feature to an existing product. But designing and building a new product from scratch, you just can't estimate that.
A: "How long will it take to write the driver?" B: "I don't know, we don't have documentation yet." A: "Well make a wild ass guess then, I need a number to fill in." B: "Um, 6 months." A: "Stop sandbagging." B: "Ok, six hours." A: "Really, that fast?"
Replace customer with product/project manager and that sounds right too.
But reality need not intrude on the process. I remember something I worked on that got a product of the year award based solely upon a mock-up when the real product wasn't even functional.
We're being asked to create a time machine. The physics for this does not yet exist. Execs tell us we have 12 months and they're already negotiating with a customer on this. Whoops it won't get done, no matter how many meetings we hold to discuss why we haven't achieved a scientific breakthrough yet.
It's extreme, but there are real life roadblocks that you can't overcome and execs can never understand this (they don't even understand how their own products work). 9 months late on a project I was working on part time, most of that delay was due entirely to a partner being slow. Waited 6 months once for legal to finish up a NDA agreement so I could get access to source code (despite my 6 month bonus/goals being all tied up in that). I have hardware thrown over the wall at me that won't work right. Or developing using a chip that's still in beta, with tools that don't work, and third party support that take weeks or months to get questions answered. The schedule is planned before the project is fully defined, we were told we had to guess what tasks were needed and how long each task would take despite no one on the team ever having done something similar, the majority of those tasks changed or were dropped, some of the already too small team left the company along the way, etc.
I was at once place that was the very best at estimating times. I was surprised at how detailed they got everything with all the parts showing up at the right time. But even then they had several releases where features were dropped at the last minute so the release manager could proclaim "we're on time!"
If you can predict with certainty how long something will take on the first week of a project, then you're probably doing something short and simple, your certainty isn't matching reality, or you're in the management track.
Reference counts can lead to loops which then results in memory that is not reclaimed. Its also wasteful of memory compared to just having two or three bits. Then what if you overflow your reference count? A "real" garbage collector can make good use of modern CPUs (like dirty bits on pages, etc) and are faster than reference counting and malloc/free. They actually move stuff around in memory which also improves locality of reference as well.
But they don't fit in well with most languages that have pointers, and especially in C++. Garbage collection is best in languages that don't have allocation or freeing of memory. The best C++ has is a best-effort approach that claims to find "most" garbage and it doesn't attempt to move memory around.
Multicore should make garbage collection easier, because GC is something that runs on the side of the program. No need to interleave GC steps into your program when it can run as a separate task. But language implementers seem have forgotten how to do this stuff, or never learned in the first place. The computing world today is designed around the idea that you can always throw more memory at a problem.
I hate patterns. They're too much like verses from a religious text, because I've run across people who seem unable to understand your code unless it uses patterns from the official pattern Bible. Holding a conversation with them can involve being interrupted every few minutes with "oh, that's a FurblingFunctorFactory, why didn't you say so?" If you don't keep a close watch they'll go and changing existing/working code to rename classes to indicate what pattern they are.
Ya, but Boost is a bit strange in my view. It's heavy heavy templated code nearly impossible to debug. It violates the "keep it simple" technique I like to use. Maybe there are parts of Boost that are decent though.
True, it's not really a GC technique. But... I have seen garbage collectors in some popular interpreters still doing this. Reference counting is good for things with a low reference count - like number of users of a file or window.
However sometimes reference counting can pass the buck on responsibility. Ie, if I "know up front" that I can alloc memory, call a sequence of functions, then free the memory then this should be adequate. If some in a called function retains a reference to the memory then that's an error that needs to be fixed. But because shared_ptr is so easy to use I have seen people use that technique to mask the error, as if it was better to leak the memory than to locate and fix the bug.
I worked on medical devices at two companies, and there is a LOT of documentation and a LOT of process and a lot of training about how to deal with it all. A variety of standards you have to comply with, randomized audits, etc. (we had one standard from Japan that required us to verify that we were vermin free, presumably to prove we weren't a sweat shop)
"Engineering" is just a title. People like to think that software is full of lots of engineer wannabes that don't know good engineering practices. However in practice the hardware people are just as bad and sometimes worse! Plenty of hardware departments don't like to use version control systems, they make wild ass guesses on values of components, cross checking amongst engineers is rare, and they're every bit as much a slave to the deadlines. I think software people often get this inferiority complex about not being a "real" engineer and this actually makes them want to document things more.
The snag is that they've tied everything together in cars. Bad engineering design in many ways, but good engineering if your goal is to develop quickly and not worry about security. Thus if the user is allowed to change the software for the entertainment system on the dashboard, that same software can screw up the engine. One network to control them all. You want a firewall between the engine and the passenger compartment; but you also want a firewall between different major components.
If you can shut down some autos by programming firmware on the radio over the air, then that makes me think that I don't want random people mucking with the source code until they fix the designs.
I think it's cute that the summary describes something incredibly obvious to anyone on slashdot. "Sofware development audit trail." Oh, it means source code control, just see who checked in the code. Duh.
The "test audit trail" though sounds like an advertisement for a package that offers this. As in if VW had used our spiffy SmartBear software then we'd be able to do an audit and arrest the right people, says sales person hoping to collect more commissions.
Slashdot Mirror
Go to Europe. The low emissions were a major part of their marketing. The fraud goes beyond the EPA most likely, there is evidence of test cheating in Europe now too, and many countries are opening up investigations. Sure, in the US many people here don't give a shit about clean air, but the fraction of VW diesels in the US is tiny. In Europe VW is much bigger and the percentage of diesels is much higher, so this is a much bigger scandal than just the insular United States.
Sure we gain more. We send a big mesasge that no one is too big to fail or too big to be above the law.
If a company gets only a slap on the wrist, you can never trust them again to have learned their lesson.
This scandal is going to be huge, and they're going to lose a massive amount of stock price and market share. This is not just an issue with EPA rules and tiny fraction of the US market. VW is so much bigger in Europe, there are so many more diesels sold there, and the market there in general cares a lot more about low emissions than in the US. In the US it may be fraud that can be overlooked because we like powerful cars here, but in EU the fraud won't be brushed off as petty shenanigans. Investigations are opening up around the world and there are hints that this cheating also is going on beyond just the American market. Then going further, there's going to be a huge scandal all over if it turns out the government testers in the EU who were posted inside the auto plants failed to detect these problems (or more likely, failed to report).
Although the summary is misleading, I think there are people very confused about the social aspect of social media. A Facebook friend is not necessarily a friend. Being unfriended does not mean you lost a friend.
I never even realized slashdot had ads, until once day there was a notice up top that said I was eligible to disable advertisements...
Right. But I'm on a brand new product. It doesn't exist yet. There are no customers. The internal requirements being driven from outside of engineering keep fluctuating as they try to identify potential customers and guess what they want. But there's no guarantee that the end goal is even achievable, the parts being relied upon don't do what their marketing claim for example.
Even if it's just a feature added to an existing product, I have seen cases where there is just not enough evidence at the start to indicate whether the feature is even feasible much less how long it will take. Such as, will it fit in the remaining memory or will we have to wait for a next generation hardware platform? That's why it's called R&D - you start with the Research and then later the Development. But there are places that start with the D instead, and only occasionally get around to the R.
But it's been a while since I've worked anywhere where customers were so closely tied to requirements. The releases and products are usually intended for many or all customers. Though I did work at one place a long time ago when every release was used only by one customer, and everything felt random and support was a nightmare. Never want to go back to that sort of environment.
Yes all that stuff too. I was the C++ "expert" at one company, meaning the one who translated the obscure gcc error messages, and who kept the runtime working. And Boost was difficult to maintain at times.
But they don't. Seriously, they don't.
I think people that are good at estimates are doing the same things over and over. Such as adding a small feature to an existing product. But designing and building a new product from scratch, you just can't estimate that.
A: "How long will it take to write the driver?"
B: "I don't know, we don't have documentation yet."
A: "Well make a wild ass guess then, I need a number to fill in."
B: "Um, 6 months."
A: "Stop sandbagging."
B: "Ok, six hours."
A: "Really, that fast?"
Replace customer with product/project manager and that sounds right too.
But reality need not intrude on the process. I remember something I worked on that got a product of the year award based solely upon a mock-up when the real product wasn't even functional.
It's Twitter. They could allow 160MB of characters and still not have any depth.
We're being asked to create a time machine. The physics for this does not yet exist. Execs tell us we have 12 months and they're already negotiating with a customer on this. Whoops it won't get done, no matter how many meetings we hold to discuss why we haven't achieved a scientific breakthrough yet.
It's extreme, but there are real life roadblocks that you can't overcome and execs can never understand this (they don't even understand how their own products work). 9 months late on a project I was working on part time, most of that delay was due entirely to a partner being slow. Waited 6 months once for legal to finish up a NDA agreement so I could get access to source code (despite my 6 month bonus/goals being all tied up in that). I have hardware thrown over the wall at me that won't work right. Or developing using a chip that's still in beta, with tools that don't work, and third party support that take weeks or months to get questions answered. The schedule is planned before the project is fully defined, we were told we had to guess what tasks were needed and how long each task would take despite no one on the team ever having done something similar, the majority of those tasks changed or were dropped, some of the already too small team left the company along the way, etc.
I was at once place that was the very best at estimating times. I was surprised at how detailed they got everything with all the parts showing up at the right time. But even then they had several releases where features were dropped at the last minute so the release manager could proclaim "we're on time!"
If you can predict with certainty how long something will take on the first week of a project, then you're probably doing something short and simple, your certainty isn't matching reality, or you're in the management track.
Reference counts can lead to loops which then results in memory that is not reclaimed. Its also wasteful of memory compared to just having two or three bits. Then what if you overflow your reference count? A "real" garbage collector can make good use of modern CPUs (like dirty bits on pages, etc) and are faster than reference counting and malloc/free. They actually move stuff around in memory which also improves locality of reference as well.
But they don't fit in well with most languages that have pointers, and especially in C++. Garbage collection is best in languages that don't have allocation or freeing of memory. The best C++ has is a best-effort approach that claims to find "most" garbage and it doesn't attempt to move memory around.
Multicore should make garbage collection easier, because GC is something that runs on the side of the program. No need to interleave GC steps into your program when it can run as a separate task. But language implementers seem have forgotten how to do this stuff, or never learned in the first place. The computing world today is designed around the idea that you can always throw more memory at a problem.
I hate patterns. They're too much like verses from a religious text, because I've run across people who seem unable to understand your code unless it uses patterns from the official pattern Bible. Holding a conversation with them can involve being interrupted every few minutes with "oh, that's a FurblingFunctorFactory, why didn't you say so?" If you don't keep a close watch they'll go and changing existing/working code to rename classes to indicate what pattern they are.
Yes, C++ has nicer ways to manage this, and I've used them.
Ya, but Boost is a bit strange in my view. It's heavy heavy templated code nearly impossible to debug. It violates the "keep it simple" technique I like to use. Maybe there are parts of Boost that are decent though.
True, it's not really a GC technique. But... I have seen garbage collectors in some popular interpreters still doing this. Reference counting is good for things with a low reference count - like number of users of a file or window.
However sometimes reference counting can pass the buck on responsibility. Ie, if I "know up front" that I can alloc memory, call a sequence of functions, then free the memory then this should be adequate. If some in a called function retains a reference to the memory then that's an error that needs to be fixed. But because shared_ptr is so easy to use I have seen people use that technique to mask the error, as if it was better to leak the memory than to locate and fix the bug.
It's a huge amount if you just want to try it out.
This is why apps are so popular. Sorry, I mean this is why writing apps is so popular.
I worked on medical devices at two companies, and there is a LOT of documentation and a LOT of process and a lot of training about how to deal with it all. A variety of standards you have to comply with, randomized audits, etc. (we had one standard from Japan that required us to verify that we were vermin free, presumably to prove we weren't a sweat shop)
"Engineering" is just a title. People like to think that software is full of lots of engineer wannabes that don't know good engineering practices. However in practice the hardware people are just as bad and sometimes worse! Plenty of hardware departments don't like to use version control systems, they make wild ass guesses on values of components, cross checking amongst engineers is rare, and they're every bit as much a slave to the deadlines. I think software people often get this inferiority complex about not being a "real" engineer and this actually makes them want to document things more.
The snag is that they've tied everything together in cars. Bad engineering design in many ways, but good engineering if your goal is to develop quickly and not worry about security. Thus if the user is allowed to change the software for the entertainment system on the dashboard, that same software can screw up the engine. One network to control them all. You want a firewall between the engine and the passenger compartment; but you also want a firewall between different major components.
If you can shut down some autos by programming firmware on the radio over the air, then that makes me think that I don't want random people mucking with the source code until they fix the designs.
I think it's cute that the summary describes something incredibly obvious to anyone on slashdot. "Sofware development audit trail." Oh, it means source code control, just see who checked in the code. Duh.
The "test audit trail" though sounds like an advertisement for a package that offers this. As in if VW had used our spiffy SmartBear software then we'd be able to do an audit and arrest the right people, says sales person hoping to collect more commissions.
Why does a mountain climber climb a mountain?
Lack of proper outlets for creativity in the home?
Really? The "@" wasn't good enough?
They just added one more emoji, the keyboard is now obsolete...