And when those passengers get off the plane thinking they can fly without a plane? I suspect this would have an adverse affect on repeat business. Even worse, all of the people who fly for business would be forced to take the bus so they're remotely functional when they get to their destination.
I suspect that in general, the people who have the time and money to build kit/custom cars have the money to put up a bond to self-insure.
I doubt any auto maker is big enough to lock electric cars out of the market by controlling insurance companies. There will always be someone who is willing to insure electric cars if there are enough of them on the road to make it profitable. Worst case scenario would be the electric car manufacturer also being the insurer. It may be a headache for early adopters, but the market will work it out.
It can if you're talking physics, it's done all the time with RC helicopters which can hover inverted just fine. If you're talking about any aircraft that the FAA would certify, there's no way that would ever happen. The idea of this aircraft being used as drones would provide lots of real world experience in unexpected failure modes without people getting killed.
Back in the old days, people made stuff without planned obsolescence as a design criteria. I have an HP 49G+ with a keyboard that feels worn out, with the keys being all wobbly, and 48S and 48G which are much older and still feel solid. With a 10+ year head start, almost every other product you can think of would have the older one in worse condition. You can regularly find people on eBay paying over $200 for a HP48GX, because the newer calculators aren't built to be used like the old ones were. Paying more for a slower calculator with less memory isn't because these people are luddites, they just know the difference in quality that comes with that faster processor. I still have my calculators from high school and college (all 20+ years old at this point) and none of them have just died out of the blue. The reason people get irate is because they're not being sold a new calculator like the one they had, they're being sold one that is much cheaper to make and is expected to wear out much faster.
Calculators are things that should last forever with proper care, they're not cell phones which are designed to biodegrade in open air in less than 2 years so they can make you buy another one.
There's no such thing as a "Moon Troy Ounce", making spot prices dubious for interplanetary exchange. That's one of the fundamental flaws in our commodity markets which can be exploited by people who understand science. =)
My wife had her own HP48S when we got together. While it's nice to have a wife who can do RPN without any help, MY calculators seem to disappear sometimes. I have to litter them all around the house.
Calculators are special purpose devices, useful for special purpose applications. I can look at a screen full of horribly formatted data and if I'm adding 10 8-12 digit numbers, I can key them into a calculator faster than I can copy and paste them into a spreadsheet or a calculator program. For thousands of calculations, I'll write a program to parse the data, but for a handful of quick off the cuff calculations a device that has a lot of buttons is much faster and more useful than anything that involves a mouse.
I've been using HP 48's for about 15 years now, so I may be biased towards tools that just work. If eBay prices for old HP 48's are any indication, I'm not the only one who still sees them as useful.
Since I couldn't figure out if there was a non-Unity option from within Unity, I was about ready to give up on Ubuntu entirely before I figured out that you could log out and log in with classic to get rid of that steaming pile.
The very concept of preponing a meeting is intrinsically offensive to Americans. The question presumes that the reason the meeting was scheduled for next week is completely arbitrary, and doesn't represent the first available time that that all parties are available. It implies that in other cultures, a meeting could be scheduled for next month with absolutely no thought put into that date or how it may impact other people's plans or schedules. It's even more offensive when you do confirm that yes, in fact, next month's meeting CAN be preponed to this afternoon, since nobody was actually doing anything.
I prefer to place the comments above, if a statement, or below if part of an if condition. 1k of comments to explain those 50 characters will either help your successor, or clarify to them why they should not touch what they do not understand.
We exist. It's really pretty simple, achieve enlightenment, then the regular expressions will get you. It's much harder the other way around.
I once wrote a program that read tables from a database to generate regular expressions to parse really messed up addresses (third world, not easy US style). The regex generated the Perl variables that would populate the database table. I think the largest of the expressions was ~43k, hence why the regex was generated, being a concept that was used in the code, but never appeared, for the intense fear it would incite. 10 pages of code and a few tables to replace an expensive program we bought that didn't work.
As with any type of programming, you have to look at it from the computer's perspective and understand how the computer will feel about the code you're feeding it.
The difference is that those are federally protected groups. You may not discriminate on those criteria without running afoul of the law. You can discriminate against someone because they have been convicted of a crime(even if not relevant to the job), are incompetent, publicly express strong political opinions that contradict the employer's purpose, etc. You can't expect a military contracting company to hire a well known anti-war provocateur, can you? A prosecutor's office would not hire a pro-marijuana crusader, would they?
There's definitely a lot of grey area where you could make a reasonable sounding argument to fire someone in a protected group based on some non-protected activity, but that's where consistency matters. If the company fires a black person for the same activity that a white person receives no attention for, they're going to have problems.
I agree with the ruling, but I think it's important for both companies and employees to be sensible about their expectations. I don't name my employer when making statements about the industry, even though my statements may not be related to my current or past employers. I also do not use my work email address for anything non-work related. Many companies have policies about these types of behavior, but they're often vague and not enforced. There are far more employers looking the other way than ones who have the spare time and money to play big brother.
Are you suggesting that tech support isn't already done by tarot? Each person you talk to has a completely different, but random answer, and none of them have any familiarity with the products they support. How else could you explain that without tarot?
Why does the blame matter? That's all political BS. I don't care if I get blamed for my manager's incompetence. I've had my manager replace my name with his on stuff and take all the credit for it. That kind of stuff really doesn't matter, because I'm paid hourly for all of the time I work. Every time my advice is ignored, we create some total mess that results in more billable hours. As long as I keep getting paid, I don't care if only a small group of people know why they keep paying me. As long as my boss's boss's boss signs off on paying me more than they're supposed to pay us little IT people, I'm going to keep doing what I can to help solve problems, and if that means taking the blame for someone else's poor decision, oh well.
Why is this moderated funny? People in India are pressured to move to management after they get 2-3 years of on the job experience. The ones who stay technical go to a country that pays more. Fixing what offshore can't do or comprehend is a valid talent that still commands good salaries.
It's entirely possible that a dramatic magnetic shift could cause disruption to electronic services, and I'm sure that if Facebook were down for days, there are millions of people who would just die.
I'm pretty sure that business schools teach people that you can borrow against the future forever. After all, if go out of business, the interest you owe to the future becomes irrelevant. If you've moved onto another job by the time you have to pay the piper, you can claim success while your successors are the failures for not moving faster.
From a business standpoint, russian roulette is the best possible business model. What other gamble offers you an 80% chance of winning? Business schools weed out the analytical types who ask about the other 20%.
Unfortunately, testing is one of those things that you're never going to convince anyone will save any money. If you've always been doing it, you can't prove otherwise. If you never did it, how could you have made it so far if testing was so important? I'm all in favor of good development practices, but there's no way to make a business case for trying to achieve the stability and durability of a pyramid when you have the budget and manpower for a shanty town.
Or in the case of fields like marketing and insurance, causation is irrelevant if the correlation is strong enough.
If teenagers have a 1% chance of getting into an accident in their first year being insured with the company, but ones with red cars have a 3% rate, you don't have to prove any causal relationship between car color and ability to drive, you just play the numbers and raise rates accordingly. Business decisions don't have to be rational, they just need to be right 51% of the time to stay in business.
The old addage of quality, cost, time - choose two holds here. You're absolutely right that when quality is negotiable, cost and time are much more flexible. For us, we could throw away 5% of the data and it met spec.
Many years ago I set up mechanical engineering systems that performed simulations of stress when operating at 8 kelvin. The calculations in a system like that must be done right and have to adhere to strict requirements. However, I suspect the same group of programmers who wrote those parts of the code also wrote the daylight savings time conversion that caused the job scheduler to always think it was 2 hours in the future. The sign was wrong and the vendor was on the east coast, we were on the west coast. They couldn't reproduce the problem. Some aspects of projects may have a higher quality threshold than others, but overall the approach can work if applied in a thoughtful manner. From the customer's standpoint, a fair amount of effort to debug a problem with the scheduler is annoying, bugs in the simulation code would be unacceptable and extremely expensive.
If the core goal keeps changing, you're doomed. However, it's possible to make major changes to key requirements in order to keep the project on track.
I implemented a data warehouse where we had purchased some address parsing software. The addresses in places like Brazil and Mexico are incredibly inconsistent compared to US addresses, so the software simply did not work. We could have spent an infinite amount of time trying to customize the software we bought to do what we needed and it simply could not have worked. Instead, I wrote my own process from scratch that ran circles around anything we could get out of the software we bought, so we abandoned that investment and used my code. That was one of 3 major components in the process that had to be completely rewritten. Sometimes the right solution is to recognize that starting over is the fasted and most productive path, regardless of previous investment of time and money.
The goal, even if somewhat vague, should be solid and understood by everyone. The agile approach is about starting small and making it better. Nothing ever gets to perfection with the agile approach, but if you get things to be good enough on the key features, it counts as a success. If only Microsoft could raise their standards to "good enough". =)
The reason it looks like magic is because it requires at least one person who Truly Gets It. It's easy to get business people to buy flash, because they cannot measure substance, nor can they differentiate between skill and luck with past experience.
For Agile methods to work, you need at least one person who sees the whole big picture, and given enough time and/or other good people to work with, could implement everything from scratch. Once you have that person and a commitment to make the project work, you'll succeed. If you don't have that person, your odds are just as good as any other poorly managed software project.
I worked on a project where we had 6 months to do more than others had done in 18-24 months in the past. The requirements were subject to change on the fly, but the big picture was understood well enough by everyone to make sure that we kept going down the right path. We bought three off the shelf software components that were supposed to be the building blocks of the project. In the end, we used one, abandoned one, and had to do a lot of work to make the third one usable for our purposes. From a functionality perspective, buying the software covered 10-20% of the work that needed to be done to create a viable solution.
There were several times where the management direction would have badly crippled us further into development. However, our management trusted our recommendations and later in the process learned that what we were advocating had been right all along, but wasn't obvious until core requirements changed later.
Without someone who has a deep understanding of software development and all of the things that go into it, the whole process looks like magic.
If you have 100 PC's, you should have a business case for more than one person to support those. Do you really want your end users calling Dell as the first line support? The end user probably doesn't know how to diagnose various types of hardware issues, or contrast those with software issues that the vendor isn't going to solve. If you think Dell phone support is the solution for this, your people will be wasting a lot of time on the phone with customer service.
When you focus on having replaceable cogs, that makes for a great justification to never do anything smart or efficient. I work in a large company that takes this approach to support, which means we don't get the benefits of having smart people around, other than their ability to solve problems that never would have occurred if we didn't use the cog philosophy as an excuse to avoid sustainable infrastructure practices. This provides a lot of billable hours for contractors, but otherwise has little merit.
Slashdot Mirror
And when those passengers get off the plane thinking they can fly without a plane? I suspect this would have an adverse affect on repeat business. Even worse, all of the people who fly for business would be forced to take the bus so they're remotely functional when they get to their destination.
I suspect that in general, the people who have the time and money to build kit/custom cars have the money to put up a bond to self-insure.
I doubt any auto maker is big enough to lock electric cars out of the market by controlling insurance companies. There will always be someone who is willing to insure electric cars if there are enough of them on the road to make it profitable. Worst case scenario would be the electric car manufacturer also being the insurer. It may be a headache for early adopters, but the market will work it out.
It can if you're talking physics, it's done all the time with RC helicopters which can hover inverted just fine. If you're talking about any aircraft that the FAA would certify, there's no way that would ever happen. The idea of this aircraft being used as drones would provide lots of real world experience in unexpected failure modes without people getting killed.
Back in the old days, people made stuff without planned obsolescence as a design criteria. I have an HP 49G+ with a keyboard that feels worn out, with the keys being all wobbly, and 48S and 48G which are much older and still feel solid. With a 10+ year head start, almost every other product you can think of would have the older one in worse condition. You can regularly find people on eBay paying over $200 for a HP48GX, because the newer calculators aren't built to be used like the old ones were. Paying more for a slower calculator with less memory isn't because these people are luddites, they just know the difference in quality that comes with that faster processor. I still have my calculators from high school and college (all 20+ years old at this point) and none of them have just died out of the blue. The reason people get irate is because they're not being sold a new calculator like the one they had, they're being sold one that is much cheaper to make and is expected to wear out much faster.
Calculators are things that should last forever with proper care, they're not cell phones which are designed to biodegrade in open air in less than 2 years so they can make you buy another one.
There's no such thing as a "Moon Troy Ounce", making spot prices dubious for interplanetary exchange. That's one of the fundamental flaws in our commodity markets which can be exploited by people who understand science. =)
My wife had her own HP48S when we got together. While it's nice to have a wife who can do RPN without any help, MY calculators seem to disappear sometimes. I have to litter them all around the house.
Calculators are special purpose devices, useful for special purpose applications. I can look at a screen full of horribly formatted data and if I'm adding 10 8-12 digit numbers, I can key them into a calculator faster than I can copy and paste them into a spreadsheet or a calculator program. For thousands of calculations, I'll write a program to parse the data, but for a handful of quick off the cuff calculations a device that has a lot of buttons is much faster and more useful than anything that involves a mouse.
I've been using HP 48's for about 15 years now, so I may be biased towards tools that just work. If eBay prices for old HP 48's are any indication, I'm not the only one who still sees them as useful.
Since I couldn't figure out if there was a non-Unity option from within Unity, I was about ready to give up on Ubuntu entirely before I figured out that you could log out and log in with classic to get rid of that steaming pile.
The very concept of preponing a meeting is intrinsically offensive to Americans. The question presumes that the reason the meeting was scheduled for next week is completely arbitrary, and doesn't represent the first available time that that all parties are available. It implies that in other cultures, a meeting could be scheduled for next month with absolutely no thought put into that date or how it may impact other people's plans or schedules. It's even more offensive when you do confirm that yes, in fact, next month's meeting CAN be preponed to this afternoon, since nobody was actually doing anything.
I prefer to place the comments above, if a statement, or below if part of an if condition. 1k of comments to explain those 50 characters will either help your successor, or clarify to them why they should not touch what they do not understand.
We exist. It's really pretty simple, achieve enlightenment, then the regular expressions will get you. It's much harder the other way around.
I once wrote a program that read tables from a database to generate regular expressions to parse really messed up addresses (third world, not easy US style). The regex generated the Perl variables that would populate the database table. I think the largest of the expressions was ~43k, hence why the regex was generated, being a concept that was used in the code, but never appeared, for the intense fear it would incite. 10 pages of code and a few tables to replace an expensive program we bought that didn't work.
As with any type of programming, you have to look at it from the computer's perspective and understand how the computer will feel about the code you're feeding it.
The difference is that those are federally protected groups. You may not discriminate on those criteria without running afoul of the law. You can discriminate against someone because they have been convicted of a crime(even if not relevant to the job), are incompetent, publicly express strong political opinions that contradict the employer's purpose, etc. You can't expect a military contracting company to hire a well known anti-war provocateur, can you? A prosecutor's office would not hire a pro-marijuana crusader, would they?
There's definitely a lot of grey area where you could make a reasonable sounding argument to fire someone in a protected group based on some non-protected activity, but that's where consistency matters. If the company fires a black person for the same activity that a white person receives no attention for, they're going to have problems.
I agree with the ruling, but I think it's important for both companies and employees to be sensible about their expectations. I don't name my employer when making statements about the industry, even though my statements may not be related to my current or past employers. I also do not use my work email address for anything non-work related. Many companies have policies about these types of behavior, but they're often vague and not enforced. There are far more employers looking the other way than ones who have the spare time and money to play big brother.
Are you suggesting that tech support isn't already done by tarot? Each person you talk to has a completely different, but random answer, and none of them have any familiarity with the products they support. How else could you explain that without tarot?
Why does the blame matter? That's all political BS. I don't care if I get blamed for my manager's incompetence. I've had my manager replace my name with his on stuff and take all the credit for it. That kind of stuff really doesn't matter, because I'm paid hourly for all of the time I work. Every time my advice is ignored, we create some total mess that results in more billable hours. As long as I keep getting paid, I don't care if only a small group of people know why they keep paying me. As long as my boss's boss's boss signs off on paying me more than they're supposed to pay us little IT people, I'm going to keep doing what I can to help solve problems, and if that means taking the blame for someone else's poor decision, oh well.
Why is this moderated funny? People in India are pressured to move to management after they get 2-3 years of on the job experience. The ones who stay technical go to a country that pays more. Fixing what offshore can't do or comprehend is a valid talent that still commands good salaries.
It's entirely possible that a dramatic magnetic shift could cause disruption to electronic services, and I'm sure that if Facebook were down for days, there are millions of people who would just die.
I'm pretty sure that business schools teach people that you can borrow against the future forever. After all, if go out of business, the interest you owe to the future becomes irrelevant. If you've moved onto another job by the time you have to pay the piper, you can claim success while your successors are the failures for not moving faster.
From a business standpoint, russian roulette is the best possible business model. What other gamble offers you an 80% chance of winning? Business schools weed out the analytical types who ask about the other 20%.
Unfortunately, testing is one of those things that you're never going to convince anyone will save any money. If you've always been doing it, you can't prove otherwise. If you never did it, how could you have made it so far if testing was so important? I'm all in favor of good development practices, but there's no way to make a business case for trying to achieve the stability and durability of a pyramid when you have the budget and manpower for a shanty town.
If there's an anti-photon, would that mean that black holes are just anti-matter stars?
Or in the case of fields like marketing and insurance, causation is irrelevant if the correlation is strong enough.
If teenagers have a 1% chance of getting into an accident in their first year being insured with the company, but ones with red cars have a 3% rate, you don't have to prove any causal relationship between car color and ability to drive, you just play the numbers and raise rates accordingly. Business decisions don't have to be rational, they just need to be right 51% of the time to stay in business.
Bad coding is never deliberate. It is an art that can only be attained by the truly uninformed.
Having worked for a marketing group, I would bet this is working exactly as intended as far as browser based rates go.
The old addage of quality, cost, time - choose two holds here. You're absolutely right that when quality is negotiable, cost and time are much more flexible. For us, we could throw away 5% of the data and it met spec.
Many years ago I set up mechanical engineering systems that performed simulations of stress when operating at 8 kelvin. The calculations in a system like that must be done right and have to adhere to strict requirements. However, I suspect the same group of programmers who wrote those parts of the code also wrote the daylight savings time conversion that caused the job scheduler to always think it was 2 hours in the future. The sign was wrong and the vendor was on the east coast, we were on the west coast. They couldn't reproduce the problem. Some aspects of projects may have a higher quality threshold than others, but overall the approach can work if applied in a thoughtful manner. From the customer's standpoint, a fair amount of effort to debug a problem with the scheduler is annoying, bugs in the simulation code would be unacceptable and extremely expensive.
If the core goal keeps changing, you're doomed. However, it's possible to make major changes to key requirements in order to keep the project on track.
I implemented a data warehouse where we had purchased some address parsing software. The addresses in places like Brazil and Mexico are incredibly inconsistent compared to US addresses, so the software simply did not work. We could have spent an infinite amount of time trying to customize the software we bought to do what we needed and it simply could not have worked. Instead, I wrote my own process from scratch that ran circles around anything we could get out of the software we bought, so we abandoned that investment and used my code. That was one of 3 major components in the process that had to be completely rewritten. Sometimes the right solution is to recognize that starting over is the fasted and most productive path, regardless of previous investment of time and money.
The goal, even if somewhat vague, should be solid and understood by everyone. The agile approach is about starting small and making it better. Nothing ever gets to perfection with the agile approach, but if you get things to be good enough on the key features, it counts as a success. If only Microsoft could raise their standards to "good enough". =)
The reason it looks like magic is because it requires at least one person who Truly Gets It. It's easy to get business people to buy flash, because they cannot measure substance, nor can they differentiate between skill and luck with past experience.
For Agile methods to work, you need at least one person who sees the whole big picture, and given enough time and/or other good people to work with, could implement everything from scratch. Once you have that person and a commitment to make the project work, you'll succeed. If you don't have that person, your odds are just as good as any other poorly managed software project.
I worked on a project where we had 6 months to do more than others had done in 18-24 months in the past. The requirements were subject to change on the fly, but the big picture was understood well enough by everyone to make sure that we kept going down the right path. We bought three off the shelf software components that were supposed to be the building blocks of the project. In the end, we used one, abandoned one, and had to do a lot of work to make the third one usable for our purposes. From a functionality perspective, buying the software covered 10-20% of the work that needed to be done to create a viable solution.
There were several times where the management direction would have badly crippled us further into development. However, our management trusted our recommendations and later in the process learned that what we were advocating had been right all along, but wasn't obvious until core requirements changed later.
Without someone who has a deep understanding of software development and all of the things that go into it, the whole process looks like magic.
So the patent lawyers go up against the wall first, problem solved.
If you have 100 PC's, you should have a business case for more than one person to support those. Do you really want your end users calling Dell as the first line support? The end user probably doesn't know how to diagnose various types of hardware issues, or contrast those with software issues that the vendor isn't going to solve. If you think Dell phone support is the solution for this, your people will be wasting a lot of time on the phone with customer service.
When you focus on having replaceable cogs, that makes for a great justification to never do anything smart or efficient. I work in a large company that takes this approach to support, which means we don't get the benefits of having smart people around, other than their ability to solve problems that never would have occurred if we didn't use the cog philosophy as an excuse to avoid sustainable infrastructure practices. This provides a lot of billable hours for contractors, but otherwise has little merit.