None of this is "silly." 18 pounds of additional weight requires an additional gallon of fuel for every 40 hours of flight, perhaps 2,500 gallons of fuel over the lifetime of the aircraft. This would cost the plane's owner $12,500 in additional fuel costs (at a rate of $5.00 per gallon for jet-A.) If Boeing sells 1,000 planes, that's over a million dollars in extra fuel costs to their customers.
Would I spend $1,000,000 to prevent a fire on an aircraft? Absolutely. Would I spend that $1,000,000 if I believed the planes were safe with the batteries that the battery engineering firm signed off on? Probably not.
From a story in one of the above comments, a subcontractor's engineer working on the battery assembly was claiming it was unsafe and that his supervisor was pressuring him to sign off on the battery despite his concerns; when he failed to do so he was fired. We don't know if any of that information made it back to Boeing, but if it had, they probably would not have accepted the batteries from the supplier without further review.
HOLY SMOKES! I was imagining a crack along the side of a plastic case with some black soot along the damage. These look like they were found in the shell of a completely burned-down building.
Of course not, it's still a very useful tool, just at a certain level of performance and within certain limitations.
The same can't be said for tests, however. Current tests in the US test for rote memorization but fail to account for true understanding of the material. Does the student have an intuitive understanding of why the math works? Who cares, they memorized a few equations, and that's all the matters! A++!
Read my whole post. You can address this 'institutionalized cheating' by creating sophisticated, dynamic, randomized tests, as they would make it impossible to "teach to the test." But those tests would be very costly, and extremely difficult to administer. There isn't the political will to spend more of our education budget on standardized testing when most schools would rather have an extra teacher or two.
Most of all, there isn't yet any proof that improving the standardized testing methodology would improve student educations. Standard tests are used to allocate budgets to schools based on differences between those schools, not to evaluate the precise quality of the education to three decimal places.
A lot of people point out some specific complaints about X and Y not being accurately measured, (which may be true), but then extend it to the entire idea of testing being completely and irrevocably flawed. These are often people with some other agenda: cutting school funding, raising school funding, hiring teachers, firing teachers, all of whom are looking to use the statistics to justify their cause. Removing testing would remove the facts that inconveniently disagree with their philosophy.
I agree with you that they should only be used in aggregate. I think they're good at indicating trends at the policy-setter level -- nations, states, and districts. But below that, they get abused. Our school district used the Special Education school as a dumping ground -- all the troublemakers were shifted there where it served more as a detention facility than an education building. That school suffered on every No Child Left Behind rating, while the other schools in the district excelled. It let a bunch of people in the good schools keep their jobs, while in the bad school there seems to be no incentive to improve anything. Those kids likely won't get a quality education even if they decide to try (not that many who've had a couple of incidents ever do.) Essentially, if there's a classification of students that happens beneath the aggregate level, it's not fair to use them to judge the people who have no control over the classification process.
I'm surprised nobody here has mentioned the "fiscal printers" that keep a total of all figures printed in the right hand column. (IBM was selling them to Italian businesses decades ago.) There's a port on the printer that a tax collector can plug a device into and download the total transaction amount since the last reading. The device computes the sales tax due, and the collector demands it from the business. It doesn't matter how shady your POS software is, if the amount is printed on the receipt, they collect the tax on it. And if the amount isn't printed on the receipt, the customer doesn't pay it.
First, please try to understand that no measuring system is perfect. Is your voltmeter useless because it has only 4 digits of precision? Is it bullshit because it can't tell the difference between 4.99985 volts and 4.99975 volts? Is it bullshit because it only updates the display twice a second? Of course not, it's still a very useful tool, just at a certain level of performance and within certain limitations. Is it better than a voltmeter that has only three digits of precision? Again, "better" depends on the task you're performing. What it does provide is a standardized measure of voltage that we can agree on across the world. And that has some value.
So how do you measure a school? How do you know if a school is worth the money you give them? By measuring the output of that school. But we can't compare grades because different teachers grade different classes differently. Instead, we measure everybody with the same yardstick - standardized tests. Did these kids get taught certain basic facts about geography? Math? English? History? Science? A standardized test is not so much a measure of the kids who take it, but of the schools who prepared (or failed to prepare) their kids to take it.
Should schools teach to those tests? That is a completely different question, and you would certainly have cause to call bullshit there. No doubt many schools feel compelled to teach to the test because it's their lone measure of success when it comes time to getting funding. That's a result of rewarding performance that relies on a static measure. A more accurate system would have a new secret or randomized test published every year, but that would be fiendishly difficult and expensive to prepare and administer, and might not yield an effective improvement over today's more primitive testing methodologies. We have only a limited budget for education, and we have to decide if the money should be spent more on teaching, or on more accurate but complex and expensive testing?
And this gets us to the issue of scale. Do you know how many schools there are in America? I'd guess there are somewhere between 10,000 and 100,000. Do you know what it takes to coordinate such a test? There really isn't any practical analogue that you could compare such an effort to. Then consider that very few of those schools really want to participate or cooperate, because it's going to take time and money from budgets that are already strained. It's a huge undertaking in a semi-hostile environment, to say the least. Adding complexity is not necessarily going to make it more successful.
No, the tests are not perfect, not by a long shot. But to give up and run without any external measure, how do we know if any of the schools are delivering worthwhile educations? The only other way to measure that would be to measure the success of graduates in the marketplace, and not only would that be a horribly imperfect system, it would lag by five or ten years, far too long to make any meaningful improvements. Standardized tests are not the greatest, but they're much better than nothing at all.
As many others have pointed out in their replies to you, a good optimizer will often wash away the performance differences. Performance is one of those things that is desperately needed when it's needed, but in general It's more important to me that my code be readable and provably correct. That means using the language and statements that make my intentions clear.
As far as efficiency goes, when you see an "else if" or "case" statement, consider polymorphism and a state pattern instead. You make the decision exactly one time, at the time you learn the value of the data in the proper context. Then when it comes to the code where you would have put an if/else-if ladder or a switch/case construct, you simply dereference a pointer and are executing the proper logic. Having that one decision point serves you for all future decisions based on that data.
I mean hey, if you're going to be writing in an object oriented language, you probably ought to be using it.
I recommend writing the unit test first, describing the inputs with explanatory names (no magic numbers allowed!) and expectations in terms of assertions. Then write your code. Now you have a readable document that exactly describes how to call your code, provides a working example, and proves your code does exactly what you say it does. Explanatory comments are a lot less needed in this world.
He could offer to move to a nicer house in a nicer part of town, and sell his house to Sprint. Better, he could offer to sell his house to AT&T and let them open a ATT Wireless store in his house - after being screwed by Sprint, perhaps their frustrated customers would be looking for a change.
Oh, that's right. I completely forgot that I'm a shifty thief, hell-bent on copying everyone else's work, and that I can't be trusted to not share copies of their software. My mistake, sorry.
Car analogy fail. Licensing a car, and paying taxes on the car, goes partially to the construction and upkeep of the roads that car needs. (E.g. you don't pay those same taxes on an off road farm use vehicle, or necessarily even register it.) But the road analogy is the internet, not the publisher's servers.
Paying the manufacturer to play the game on their servers is a better analogy. You use the shared resources, you pay for their upkeep.
Paying the manufacturer to check in with their servers to bless your local copy so it can run on your local machine is the violation of principles, and probably U.S. law (see the Doctrine of First Sale.)
You also mentioned the "I'm online 100% of the time anyway", as if the convenience somehow makes it OK that they're violating you. It only makes it so simple for them to enforce that they don't get complaints from people like you, but it does not make it principled.
I completely get what you're saying. I guess I'm looking at it more cynically. If you divide the world into two sets, people who want to understand programming, and people who want the computer to do stuff for them, it's the latter that cause the problems. Everyone in your classes is of the former set, and I understand why you want them to have every opportunity to succeed. They should have it. But I have to deal with people who fall into the other set, the ones who don't want to hear about exceptions, or think that by asking about them we're trying to derail their ideas. They confuse "exception" with "problem".
Some of the more clever members of that set get it into their heads that if I can script an answer, they are smart enough to script an answer as well. "I can program my DVR, I can program this other thing too." So they're the arrogant version of script kiddies. And they cause the damage.
So yeah, we try to put rubber bumpers around the languages and systems to try to keep them from causing as much damage as possible. (So far, that has only yielded crap languages like BASIC and.Net.)
So my spin on all this is: if you want your programming students to be successful, teach them a real language, with sharp edges and all. Help them be real programmers. Leave the safe scripting languages to the unwashed masses.
We aren't at the magical level of Star Trek computers yet. One problem in particular is understanding exceptions. In the software engineering world, we understand that all kinds of things can fail. The casual scripter today doesn't understand this, that in order to have any program work that some thought must be given to the failure modes. In many cases, the failures are obvious and immediate, and can be handled manually. I scripted a phone dialer, I hear the phone is busy, I run my script again. That same person won't understand that a busy signal is always a possibility, and that their script needs to handle it. Or they may script that, but not a line-in-use case, or any other unexpected problem.
If computer systems could provide rational default behavior for every problem they might encounter, there is somewhat less of a problem. Restricting them to a limited domain, such as scripting a DVR, where all failure modes are known AND the amount of damage a mistake can cause is trivial, can make someone successful. Letting them off the reservation, to freely interconnect whatever they want in a language they barely grok, can set them up for more serious problems that they do not understand.
We have to build better systems and languages to really enable this stuff to be truly successful out in the real world, in the hands of the masses. We are not there yet, despite many tries.
Management who believes that every project must be analyzed, then designed, then coded, then tested. The IIC in our company has never written a line of software yet has built an organization that prevents anyone else from doing it efficiently, either. Since we have no development teams, just handoffs of work products, there isn't even a chance to get the right people together to do agile or even iterative work.
If we were even 5% as efficient as the rest of you developers, I would be absolutely amazed.
3D printing is perfect to let the engineers quickly assess the real-world assembly and maintainability of a prototype. Say an engineer designs the ultimate fan shroud that maximizes airflow and minimizes noise. After the product has been assembled from prototype parts, and things like the tooling and components have been ordered, a maintenance team tests the performing of a repair and replace on each of the parts. They discover the tools needed to remove the fan shroud can't fit in the space available. They give the feedback to the engineer who tweaks the design, prints out another copy with a shape better suited to the clearance available, and lets the maintenance guys test it again. Having a real part gives the engineer that feedback fast. This can reduce time of the change order by a month.
When it comes to production, it can take the tool and die guys six weeks or more to produce a new mold. Instead of holding up production until the new mold arrives, the new 3D printed part can be used to make a quickie die sintered out of powdered metal, using the part in a lost-wax cast process. It's not going to be a high quality die made of hard enough tool steel, and it won't last for thousands of parts, but they only take a few days to make. A production line can begin producing at least some parts within a week or two - maybe not full capacity, but they can get the first few units out the door. When the real mold is finally available, they can ramp up production to full capacity.
3D printing gets you to the injection molder quicker.
There are two primary contributing factors to problems with respect to badly written software. One is that it's generally difficult to look at the software externally and determine its quality. I'm not an automotive engineer, but I can look at a 1980 Chevette, take it for a test drive, and determine that it was built from duct tape, bubblegum, and staples, and was not a well made vehicle. The same is less possible with software, which often doesn't offer those externally visible clues; and it's even more of a problem for non-developers to see its quality (or the lack thereof.)
The other half of the problem is that providing solutions of any kind (not just software) enable further external dependencies upon those solutions. The fact that it's a software solution may make some people believe that it's reliable in ways that it is not.
For example, a beginner programmer might write up some home automation code that turns on a light when the garage door opens. They might then extend it to make it dial a phone and play a recording when a button is pushed. And that's absolutely a great thing, because the kid is starting to learn.
The problem starts when Uncle Joe, who is not a software engineer, says "that's really neat, now give that button to Grandma so that if she falls she can push it and we'll go help her out." But the beginner's software might have a hidden fault that causes it to only execute when the garage door is open, which it was throughout its limited testing. What has been created is a program that externally looks good, and so it gets reused, but has had insufficient testing and is in no way well-engineered or ready for production use. And nobody involved in the project understands that until it's too late.
Not recognizing that the software is bad, someone then created an external dependency on that bad software. Grandma might fall when the garage door is closed, she pushes the button instead of dialing the cell phone because she believes the button will work, and instead goes unrescued for too long.
This is of course a contrived example, but it's amazing how much bad code is woven into so many different places in the real world, with so many dependencies on it. And once you add those dependencies, it's often very hard to change them. Believe it or not, I've heard the management equivalent of "We can't take the button away from Grandma now, what if she falls again? It makes her feel better."
This is not saying its bad for people to create software. What is bad is that people don't understand that what they've created is of low quality.
Semantics. You guys are really arguing about the difference between programming (creating a set of instructions) and software development (creating a set of instructions and arranging them in such a manner such that they are testable, logically correct, meet the given requirements completely, reusable, secure, modular, efficient, and understandable and maintainable by other humans.)
Anyone can write a program, but not everyone who writes a program is a software developer. Including some software developers I know...:-/
Part of the problem is that they have to spend the entire research budget to bring a new device to the market. Agile works for software development because software is infinitely malleable, and that any mistakes can be discovered fast and fixed for a fairly low cost. Hardware development requires you to do 100% of the engineering to make the machine small, thin, strong, long life, fast, capable, etc., and then to manufacture them. Development costs are generally recouped only after many thousands of units are sold. And as far as making any mistakes, well, recalls and warranty work are very expensive, and liability for incidental damage like fires due to faulty design is even more so.
They could try an iterative approach, but what are they going to tackle in pieces that people are willing to buy? As a loyal customer, would you be cheesed off if they came out with a new model every two months, each with a slight improvement to screen, keyboard, battery, whatever? (I know, Apple's doing it, but their customers aren't all continuing down the path to upgrade to the latest shiny.)
I'm not saying iterative or agile are bad (far from it), only that they are less applicable to hardware than to software.
Just to pick a nit or two, shills != trolls. And I agree that there's a lot less trolling now than there was 10 years ago, (hard to say since most of the true crap gets flagged or effectively downmodded pretty quickly) but I think political shilling has increased.
I'd love a "-1, Political" moderation. Even a "+1, Political that I agree with" moderation would be good so I could personally do the whole -6 downmod on any comment so marked.
On a real mission, the trip out is likely to be pretty much demotivational as well. "Here I am, stack of college degrees and qualifications longer than your arm, and what am I doing? Watering hydroponic plants. Oh, god, I'm so depressed."
Supposedly, that was photoshopped by someone just to piss Rusty off. It worked.
That's the thing when you run a successful site. The trolls aren't just posting garbage, they're making it personal. Community policing works only as long as the community doesn't tolerate the trolls, and I think K5 just got overrun.
A lot of people bitch about the slashdot moderation system being crap, but when you see sites like kuro5hin fail like that, you have to consider that it adds huge value.
Slashdot Mirror
None of this is "silly." 18 pounds of additional weight requires an additional gallon of fuel for every 40 hours of flight, perhaps 2,500 gallons of fuel over the lifetime of the aircraft. This would cost the plane's owner $12,500 in additional fuel costs (at a rate of $5.00 per gallon for jet-A.) If Boeing sells 1,000 planes, that's over a million dollars in extra fuel costs to their customers.
Would I spend $1,000,000 to prevent a fire on an aircraft? Absolutely. Would I spend that $1,000,000 if I believed the planes were safe with the batteries that the battery engineering firm signed off on? Probably not.
From a story in one of the above comments, a subcontractor's engineer working on the battery assembly was claiming it was unsafe and that his supervisor was pressuring him to sign off on the battery despite his concerns; when he failed to do so he was fired. We don't know if any of that information made it back to Boeing, but if it had, they probably would not have accepted the batteries from the supplier without further review.
http://www.nycaviation.com/2013/01/ntsb-shows-off-burnt-boeing-787-battery/
HOLY SMOKES! I was imagining a crack along the side of a plastic case with some black soot along the damage. These look like they were found in the shell of a completely burned-down building.
Of course not, it's still a very useful tool, just at a certain level of performance and within certain limitations.
The same can't be said for tests, however. Current tests in the US test for rote memorization but fail to account for true understanding of the material. Does the student have an intuitive understanding of why the math works? Who cares, they memorized a few equations, and that's all the matters! A++!
Read my whole post. You can address this 'institutionalized cheating' by creating sophisticated, dynamic, randomized tests, as they would make it impossible to "teach to the test." But those tests would be very costly, and extremely difficult to administer. There isn't the political will to spend more of our education budget on standardized testing when most schools would rather have an extra teacher or two.
Most of all, there isn't yet any proof that improving the standardized testing methodology would improve student educations. Standard tests are used to allocate budgets to schools based on differences between those schools, not to evaluate the precise quality of the education to three decimal places.
A lot of people point out some specific complaints about X and Y not being accurately measured, (which may be true), but then extend it to the entire idea of testing being completely and irrevocably flawed. These are often people with some other agenda: cutting school funding, raising school funding, hiring teachers, firing teachers, all of whom are looking to use the statistics to justify their cause. Removing testing would remove the facts that inconveniently disagree with their philosophy.
I agree with you that they should only be used in aggregate. I think they're good at indicating trends at the policy-setter level -- nations, states, and districts. But below that, they get abused. Our school district used the Special Education school as a dumping ground -- all the troublemakers were shifted there where it served more as a detention facility than an education building. That school suffered on every No Child Left Behind rating, while the other schools in the district excelled. It let a bunch of people in the good schools keep their jobs, while in the bad school there seems to be no incentive to improve anything. Those kids likely won't get a quality education even if they decide to try (not that many who've had a couple of incidents ever do.) Essentially, if there's a classification of students that happens beneath the aggregate level, it's not fair to use them to judge the people who have no control over the classification process.
I'm surprised nobody here has mentioned the "fiscal printers" that keep a total of all figures printed in the right hand column. (IBM was selling them to Italian businesses decades ago.) There's a port on the printer that a tax collector can plug a device into and download the total transaction amount since the last reading. The device computes the sales tax due, and the collector demands it from the business. It doesn't matter how shady your POS software is, if the amount is printed on the receipt, they collect the tax on it. And if the amount isn't printed on the receipt, the customer doesn't pay it.
First, please try to understand that no measuring system is perfect. Is your voltmeter useless because it has only 4 digits of precision? Is it bullshit because it can't tell the difference between 4.99985 volts and 4.99975 volts? Is it bullshit because it only updates the display twice a second? Of course not, it's still a very useful tool, just at a certain level of performance and within certain limitations. Is it better than a voltmeter that has only three digits of precision? Again, "better" depends on the task you're performing. What it does provide is a standardized measure of voltage that we can agree on across the world. And that has some value.
So how do you measure a school? How do you know if a school is worth the money you give them? By measuring the output of that school. But we can't compare grades because different teachers grade different classes differently. Instead, we measure everybody with the same yardstick - standardized tests. Did these kids get taught certain basic facts about geography? Math? English? History? Science? A standardized test is not so much a measure of the kids who take it, but of the schools who prepared (or failed to prepare) their kids to take it.
Should schools teach to those tests? That is a completely different question, and you would certainly have cause to call bullshit there. No doubt many schools feel compelled to teach to the test because it's their lone measure of success when it comes time to getting funding. That's a result of rewarding performance that relies on a static measure. A more accurate system would have a new secret or randomized test published every year, but that would be fiendishly difficult and expensive to prepare and administer, and might not yield an effective improvement over today's more primitive testing methodologies. We have only a limited budget for education, and we have to decide if the money should be spent more on teaching, or on more accurate but complex and expensive testing?
And this gets us to the issue of scale. Do you know how many schools there are in America? I'd guess there are somewhere between 10,000 and 100,000. Do you know what it takes to coordinate such a test? There really isn't any practical analogue that you could compare such an effort to. Then consider that very few of those schools really want to participate or cooperate, because it's going to take time and money from budgets that are already strained. It's a huge undertaking in a semi-hostile environment, to say the least. Adding complexity is not necessarily going to make it more successful.
No, the tests are not perfect, not by a long shot. But to give up and run without any external measure, how do we know if any of the schools are delivering worthwhile educations? The only other way to measure that would be to measure the success of graduates in the marketplace, and not only would that be a horribly imperfect system, it would lag by five or ten years, far too long to make any meaningful improvements. Standardized tests are not the greatest, but they're much better than nothing at all.
As many others have pointed out in their replies to you, a good optimizer will often wash away the performance differences. Performance is one of those things that is desperately needed when it's needed, but in general It's more important to me that my code be readable and provably correct. That means using the language and statements that make my intentions clear.
As far as efficiency goes, when you see an "else if" or "case" statement, consider polymorphism and a state pattern instead. You make the decision exactly one time, at the time you learn the value of the data in the proper context. Then when it comes to the code where you would have put an if/else-if ladder or a switch/case construct, you simply dereference a pointer and are executing the proper logic. Having that one decision point serves you for all future decisions based on that data.
I mean hey, if you're going to be writing in an object oriented language, you probably ought to be using it.
I recommend writing the unit test first, describing the inputs with explanatory names (no magic numbers allowed!) and expectations in terms of assertions. Then write your code. Now you have a readable document that exactly describes how to call your code, provides a working example, and proves your code does exactly what you say it does. Explanatory comments are a lot less needed in this world.
I noticed in their standards doc that they said all classes must start with "id". Classic Smurf naming convention.
It's actually called the God-damned particle, you insensitive physicist!
He could offer to move to a nicer house in a nicer part of town, and sell his house to Sprint. Better, he could offer to sell his house to AT&T and let them open a ATT Wireless store in his house - after being screwed by Sprint, perhaps their frustrated customers would be looking for a change.
Oh, that's right. I completely forgot that I'm a shifty thief, hell-bent on copying everyone else's work, and that I can't be trusted to not share copies of their software. My mistake, sorry.
Car analogy fail. Licensing a car, and paying taxes on the car, goes partially to the construction and upkeep of the roads that car needs. (E.g. you don't pay those same taxes on an off road farm use vehicle, or necessarily even register it.) But the road analogy is the internet, not the publisher's servers.
Paying the manufacturer to play the game on their servers is a better analogy. You use the shared resources, you pay for their upkeep.
Paying the manufacturer to check in with their servers to bless your local copy so it can run on your local machine is the violation of principles, and probably U.S. law (see the Doctrine of First Sale.)
You also mentioned the "I'm online 100% of the time anyway", as if the convenience somehow makes it OK that they're violating you. It only makes it so simple for them to enforce that they don't get complaints from people like you, but it does not make it principled.
I completely get what you're saying. I guess I'm looking at it more cynically. If you divide the world into two sets, people who want to understand programming, and people who want the computer to do stuff for them, it's the latter that cause the problems. Everyone in your classes is of the former set, and I understand why you want them to have every opportunity to succeed. They should have it. But I have to deal with people who fall into the other set, the ones who don't want to hear about exceptions, or think that by asking about them we're trying to derail their ideas. They confuse "exception" with "problem".
Some of the more clever members of that set get it into their heads that if I can script an answer, they are smart enough to script an answer as well. "I can program my DVR, I can program this other thing too." So they're the arrogant version of script kiddies. And they cause the damage.
So yeah, we try to put rubber bumpers around the languages and systems to try to keep them from causing as much damage as possible. (So far, that has only yielded crap languages like BASIC and .Net.)
So my spin on all this is: if you want your programming students to be successful, teach them a real language, with sharp edges and all. Help them be real programmers. Leave the safe scripting languages to the unwashed masses.
We aren't at the magical level of Star Trek computers yet. One problem in particular is understanding exceptions. In the software engineering world, we understand that all kinds of things can fail. The casual scripter today doesn't understand this, that in order to have any program work that some thought must be given to the failure modes. In many cases, the failures are obvious and immediate, and can be handled manually. I scripted a phone dialer, I hear the phone is busy, I run my script again. That same person won't understand that a busy signal is always a possibility, and that their script needs to handle it. Or they may script that, but not a line-in-use case, or any other unexpected problem.
If computer systems could provide rational default behavior for every problem they might encounter, there is somewhat less of a problem. Restricting them to a limited domain, such as scripting a DVR, where all failure modes are known AND the amount of damage a mistake can cause is trivial, can make someone successful. Letting them off the reservation, to freely interconnect whatever they want in a language they barely grok, can set them up for more serious problems that they do not understand.
We have to build better systems and languages to really enable this stuff to be truly successful out in the real world, in the hands of the masses. We are not there yet, despite many tries.
Management who believes that every project must be analyzed, then designed, then coded, then tested. The IIC in our company has never written a line of software yet has built an organization that prevents anyone else from doing it efficiently, either. Since we have no development teams, just handoffs of work products, there isn't even a chance to get the right people together to do agile or even iterative work.
If we were even 5% as efficient as the rest of you developers, I would be absolutely amazed.
3D printing is perfect to let the engineers quickly assess the real-world assembly and maintainability of a prototype. Say an engineer designs the ultimate fan shroud that maximizes airflow and minimizes noise. After the product has been assembled from prototype parts, and things like the tooling and components have been ordered, a maintenance team tests the performing of a repair and replace on each of the parts. They discover the tools needed to remove the fan shroud can't fit in the space available. They give the feedback to the engineer who tweaks the design, prints out another copy with a shape better suited to the clearance available, and lets the maintenance guys test it again. Having a real part gives the engineer that feedback fast. This can reduce time of the change order by a month.
When it comes to production, it can take the tool and die guys six weeks or more to produce a new mold. Instead of holding up production until the new mold arrives, the new 3D printed part can be used to make a quickie die sintered out of powdered metal, using the part in a lost-wax cast process. It's not going to be a high quality die made of hard enough tool steel, and it won't last for thousands of parts, but they only take a few days to make. A production line can begin producing at least some parts within a week or two - maybe not full capacity, but they can get the first few units out the door. When the real mold is finally available, they can ramp up production to full capacity.
3D printing gets you to the injection molder quicker.
I'll give it a shot.
There are two primary contributing factors to problems with respect to badly written software. One is that it's generally difficult to look at the software externally and determine its quality. I'm not an automotive engineer, but I can look at a 1980 Chevette, take it for a test drive, and determine that it was built from duct tape, bubblegum, and staples, and was not a well made vehicle. The same is less possible with software, which often doesn't offer those externally visible clues; and it's even more of a problem for non-developers to see its quality (or the lack thereof.)
The other half of the problem is that providing solutions of any kind (not just software) enable further external dependencies upon those solutions. The fact that it's a software solution may make some people believe that it's reliable in ways that it is not.
For example, a beginner programmer might write up some home automation code that turns on a light when the garage door opens. They might then extend it to make it dial a phone and play a recording when a button is pushed. And that's absolutely a great thing, because the kid is starting to learn.
The problem starts when Uncle Joe, who is not a software engineer, says "that's really neat, now give that button to Grandma so that if she falls she can push it and we'll go help her out." But the beginner's software might have a hidden fault that causes it to only execute when the garage door is open, which it was throughout its limited testing. What has been created is a program that externally looks good, and so it gets reused, but has had insufficient testing and is in no way well-engineered or ready for production use. And nobody involved in the project understands that until it's too late.
Not recognizing that the software is bad, someone then created an external dependency on that bad software. Grandma might fall when the garage door is closed, she pushes the button instead of dialing the cell phone because she believes the button will work, and instead goes unrescued for too long.
This is of course a contrived example, but it's amazing how much bad code is woven into so many different places in the real world, with so many dependencies on it. And once you add those dependencies, it's often very hard to change them. Believe it or not, I've heard the management equivalent of "We can't take the button away from Grandma now, what if she falls again? It makes her feel better."
This is not saying its bad for people to create software. What is bad is that people don't understand that what they've created is of low quality.
Semantics. You guys are really arguing about the difference between programming (creating a set of instructions) and software development (creating a set of instructions and arranging them in such a manner such that they are testable, logically correct, meet the given requirements completely, reusable, secure, modular, efficient, and understandable and maintainable by other humans.)
Anyone can write a program, but not everyone who writes a program is a software developer. Including some software developers I know... :-/
Part of the problem is that they have to spend the entire research budget to bring a new device to the market. Agile works for software development because software is infinitely malleable, and that any mistakes can be discovered fast and fixed for a fairly low cost. Hardware development requires you to do 100% of the engineering to make the machine small, thin, strong, long life, fast, capable, etc., and then to manufacture them. Development costs are generally recouped only after many thousands of units are sold. And as far as making any mistakes, well, recalls and warranty work are very expensive, and liability for incidental damage like fires due to faulty design is even more so.
They could try an iterative approach, but what are they going to tackle in pieces that people are willing to buy? As a loyal customer, would you be cheesed off if they came out with a new model every two months, each with a slight improvement to screen, keyboard, battery, whatever? (I know, Apple's doing it, but their customers aren't all continuing down the path to upgrade to the latest shiny.)
I'm not saying iterative or agile are bad (far from it), only that they are less applicable to hardware than to software.
Just to pick a nit or two, shills != trolls. And I agree that there's a lot less trolling now than there was 10 years ago, (hard to say since most of the true crap gets flagged or effectively downmodded pretty quickly) but I think political shilling has increased.
I'd love a "-1, Political" moderation. Even a "+1, Political that I agree with" moderation would be good so I could personally do the whole -6 downmod on any comment so marked.
In other words, "That thing's got to have a tail pipe."
On a real mission, the trip out is likely to be pretty much demotivational as well. "Here I am, stack of college degrees and qualifications longer than your arm, and what am I doing? Watering hydroponic plants. Oh, god, I'm so depressed."
Supposedly, that was photoshopped by someone just to piss Rusty off. It worked.
That's the thing when you run a successful site. The trolls aren't just posting garbage, they're making it personal. Community policing works only as long as the community doesn't tolerate the trolls, and I think K5 just got overrun.
A lot of people bitch about the slashdot moderation system being crap, but when you see sites like kuro5hin fail like that, you have to consider that it adds huge value.