Because they're all integrated. Your car's radar can detect that the vehicle in front of you has suddenly hit the brakes, it can sound an alarm and blink a light on the windshield warning you of a road hazard immediately ahead, the engine telemetry can talk to your ABS braking systems telling them that the car is still moving even though the brakes have locked up, your crash sensors can detect an accident, your seat belt pre-tensioners and airbag deployment systems help protect the cabin occupants in case of an accident, your entertainment system can tell your cell phone to call a number, and your telemetry system records the events. Tying them all together permits your car to help you avoid accidents, protect you in case of an impact, call an emergency services number in the event of a crash, and can even help prove to a court that you were traveling only 5 MPH and had applied the brakes two seconds before you were struck.
There are safety designs in place. The different systems tie to the CAN bus through a fairly simple and robust chip that implements the protocols, which helps insulate and isolate a faulty device from overrunning the bus. There are often multiple CAN buses in a car, with engine management and safety being isolated from cabin entertainment systems. The CAN bus protocol has a priority mechanism, where lower numbered devices take priority over higher number devices - safety systems, such as ABS, crash detection and airbag deployment, are the lowest numbers, security systems like door locks have higher numbers, and the whiz-bang gadgetry of your stereo has the highest numbers.
Furthermore, your ABS system is an active driver assistance system, but it's not your means of braking. If it fails, the hydraulics still connect your brake pedals to your wheels, and you can still maintain control of the car. The airbags are just one component of an overall safety package, so if they fail, the seat belt pre-tensioners might still work. Even if the pre-tensioners also fail, the seat belts themselves still offer protection. The steering wheel is designed to collapse in the event you hit it with your body. The body is designed with crumple zones to absorb impacts.
What they've done is to combine these pieces that have known failure rates of one per tens or hundreds of millions of miles driven, and used them to protect you in the case of a serious accident, which they know happens once per hundred thousand miles driven. The chances of the systems working together to keep you safer are much higher than the chances that they'll all fail at the moment you need them the most.
In-Car Electronics (ICE). Control console. Dash GUI. Dash interface. Driver interface. Carputer (I threw that one in to go with infotainment.:-) Make something up.
Ford's SYNC is bad, but MyTouch is abysmal. Not only do you have a touch screen, but the fixed controls are touch sensitive. Reaching for them blindly is the same as activating them. And they reportedly don't work with gloves, which may not be a problem in San Diego, but here in Minnesota that's a killer.
Older cars used to have a fairly standard interface for the in-dash radios, because they were simply radios. But with factory installed sound systems featuring a dozen independent speakers, trunk-mounted amplifiers, integrated climate controls, navigation systems, and all tied into the car's CAN bus, replacing them with an aftermarket product is much less of an option these days. On many of these tightly integrated vehicles, I fear they may never be upgradable.
Of course, not every stereo installer is going to custom sculpt a trim ring for each stereo they install. But when they do, the results can be impressive.
What amazes me is that companies like Ford refuse to acknowledge this. To me, it's incredible that they can be so stupidly focused on trying to make a product that can never be made to work properly, because humans don't work that way.
And it's not like they aren't being told this repeatedly. Consumer Reports states in every article featuring a Ford product that has their "Ford MyTouch" system that the car lost somewhere between 4 and 8 points on its overall score due to the crappy interface. And in many cases those points would take the vehicle from the middle or bottom of their grouping to the top of their category. This has been going on for every MyTouch equipped vehicle they have released since the 2012 model year.
After looking at this carefully, the conclusion I have come to is they must have some hyper-egotistical VP of infotainment who has an MBA or marketing degree but no engineering background, and he has deemed by fiat that "touch screens are what people buy on their phones, make it happen on the dashboard", ignoring the advice of his safety engineers and human factors team. Microsoft was overjoyed to sell them their misnamed SYNC system (it actually syncs with nothing) as a base product, which they then had developed by some team who had no idea they were writing a car interface, and who still think popup "Are you sure you want to exit?" dialogs are appropriate for a vehicle. I wouldn't be surprised if their next release has the Windows 8 interface, complete with animated tiles trying to tell the driver that he has a new Facebook follower, three emails, and a coupon offer for a free trial of Angry Birds.
If Ford can't change under pressure from engineers and consumers, I expect that there will be several lawsuits from the victims of distracted drivers. And that's a tragedy.
"Consider what they could be doing today if they managed to mass produce 4096 bit quantum computers. They could be intercepting all SSL traffic in real time."
Or they could just have a blanket arrangement with one or more certificate authorities to generate signed and trusted keys for any domain on request...
Why "OR"? The NSA is really more of an "AND" agency. I think we can assume that anything and everything that could be done to intercept traffic is being attempted at some level or another.
We have India offices staffed with employee developers, not contractors. And that really is the best thing about our organization - we're all in it together, so there isn't an us-versus-them mentality. It's convenient to hold contractors at arm's length, and blame them when things go awry, and it's easy to say "let's end this contract." But it's very hard when you're all reporting to the same boss. That's had a lot to do with our success.
And you're absolutely right about the time difference being an issue. But you can make it work to a degree.
They've shifted their working times to start later in the morning and end later in the evening, and we have shifted our mornings to accommodate earlier meetings. We can get two hours of overlap every day with few problems, and depending on the situation we can get an additional couple of hours. It's enough to have hand-off kinds of meetings, and to discuss a project or specific problem, but not enough to work with them in a coaching, mentoring, or close partnership kind of role. That takes expensive travel, so it doesn't happen as much as either side would like. But when it does, it's great. I have some very good friends who just happen to live on the other end of a long plane ride, and I appreciate that globalization introduced us.
You may assume that the knowledge gap between the NSA and civilian cryptographers has closed, but since we don't know their capabilities, that's only a guess.
The few things we do see coming from them look very carefully chosen to meet the public expectations. See Bruce Schneier's commentary on Skipjack. One thing we can be reasonably certain of is they never reveal all their cards when interacting with civilians.
The gap could have widened as easily as it could have been closed. The NSA hires a lot of very bright mathematicians, as well as physicists, engineers, and a lot of other skilled folk. They have proven themselves capable of not only researching novel algorithms, but of creating novel hardware on which to run it. Consider what they could be doing today if they managed to mass produce 4096 bit quantum computers. They could be intercepting all SSL traffic in real time.
That's the thing about a secret organization. We don't know their capabilities, and we may never know. We only know it's not safe to rely on an assumption that we've caught up to them.
Blocking the URLs is only one of its mechanisms. The lack of a JavaScript switch hasn't hampered its inline suppression capabilities, either. Since I normally run it trusting scripts originating from the site's domain, that isn't as much of an issue for me.
You apparently outsource your "Comment Subject" writing to the Caribbean, Jamaica, from the looks of it, or maybe Minnesota.
It's from an old South Park episode. While I wouldn't exactly call someone uncultured for not knowing that, I also wouldn't call someone on it who is obviously mocking the position it represents.
I know some great offshore developers, and I also know some American developers that aren't worth their salt. Each assessment needs to be made at a personal level; you can't make a valid blanket stereotyped claim that fits everyone.
What I see causing most of the poor quality work is developers who are suffering from idiotic corporate practices, policies, and rules. "All developers shall submit their UML drawings to the UML Governance Board, and have them approved by no less than three board members, thus ensuring quality software will be developed from them." Very few developers (onshore or offshore) are successful producing quality software in such an environment, and it's especially tough for contractors who feel constrained to follow the letter of the rules without question. Now apply that constraint to a culture that reinforces the idea to accept work tasks without question anyway, and the lack of feedback pretty much ensures you'll get unexpected results.
Take the chains off, though, and you can get spectacular results from good people. You'll never get those results from bad developers, regardless of which landmass they live on.
Farm subsidies are just one of many form of protectionism.
Protectionism isn't simply import/export tariffs. It's any government policy that works to either favor internal production or hinder the import of externally produced goods and services; more broadly, it's any government policy that impacts free market capitalism. In other words, it's a word applied whenever the government decides to spend money in one area and not another, and is generally used in a derogatory fashion by the people who were negatively impacted. California dairy farmers cry protectionism when Wisconsin dairy farmers get higher subsidies than they do. Nike claims protectionism when New Balance gets the contract for military footwear. The list is endless.
I'd say to look for more of this mistreatment and abuse.
I doubt anyone in authority (except for some really stupid cops) believes the kid is actually a threat. What the rest of them are trying to do is hold him up as a warning example to all other kids "don't make school shooting jokes or we will jail your ass for as long as we like."
The authorities in Austin are forgetting two crucial element of this whole process, though. The first is that teenage boys are capable of learning this lesson and applying rational thought to their behaviors - the number of teen drunk drivers and teens killed by texting-while-driving proves this is a futile exercise. The second is that we all have the right to free speech, and that what they're doing is far more illegal than what the kid did; at least one of these a-holes needs to end up in jail for abusing the child's rights.
Consider it from a testability standpoint. If a module is externally testable and provable, and it has a good name that defines what it does, it's a good place to draw the line. Writing testable code generally means making it readable and reusable.
The other side of that is that a large, complex piece of code is hard to test. Having a complexity metric of 15 means that trying to go through all its paths could be impractical. If it's broken into smaller methods that each encapsulate a smaller idea of the complex whole, it becomes simpler and more readable - and more testable.
I agree LoC is a crappy metric, but complexity gets closer to the heart of the problem. The higher the complexity, the less likely you are to have 100% test coverage - and that leaves room for bugs, misinterpretation, and a method that probably won't be reused.
But you forget you also have to walk back to your desk.. At that point, you have two usages of a pathing algorithm.. Which means you're repeating code, which means that using a function to enable code re-use instead makes sense. I'm hardly an advocate for complex functions (most of my code are 1 or 2 liners), but there are times when you simply cannot express something concisely in a short function, and the answer to that is *not* to artificially reduce it into code that does nothing but resides in a different location.
I think you missed his point that "heatLunch()" was far more readable than "stand/turn left/walk 4 steps...". If you were defining lunch activities, you might have a lunchtime() event that has two methods: eatLunch() and readSlashdot(). eatLunch() might be made up walkToKitchen(), prepareLunch(), eatLunch(), and goBack(). walkToKitchen() could be start=getLocation(); path=navigateFromTo(start, kitchen); walk(path). prepareLunch() could be made of of cookLunch() and serveLunch(), and so on. Each task is progressively built up from simpler subtasks.
At any point you can look at the small contents of a routine and understand what it's doing at that context, but you don't necessarily need to know the larger context you're a part of. Reading the contents of walkToKitchen() doesn't imply I have to know anything about the lunchtime() event, certainly no more than seeing me walking proves that it's lunchtime. But all together, each of those small, simple steps add up to lunchtime.
The efficiency of a system can not simply be measured by CPU cycles. It all depends on where your costs are. Efficiency has to be measured by money.
If your highest costs are in runtime efficiency, then yes, you need efficient code. But if your highest costs are in end-user time spent entering data, usability beats efficiency. If your highest costs are driven by software engineering practices, such as testability, reliability, supportability, frequent deployments, etc., then readability becomes far more important than efficiency.
The usability argument works like this: if I have to pay a barrista $10 an hour to touch 20 buttons just to place an order for coffee, and the user time per button press is 3 seconds while the system time per button is 8 milliseconds or less, the efficiency of the code is almost irrelevant. My development investment is best spent in reducing the number of button presses. If a fancy GUI and a magical "do what I want" button reduces the 20 button touches to 10, I can save 30 seconds of labor per cup of coffee. If adding that fancy GUI increases the system time from 8 milliseconds to 30 milliseconds per button press, I haven't actually incurred any additional labor costs because the system is still faster than an average human's response time (maybe not in a highly caffeinated coffee shop, but it's still far less important than saving even a single button press.)
I've found that in most business applications user time is the largest expense, by a very wide margin.
If libraries of tested proven code are cheaper than hand written assembler, I don't want to pay a developer to replicate that work, even if it would be theoretically more efficient - unless the program that they're working on has efficiency as the most important goal. If I was developing an algorithm for slinging polygons at a graphics card, you better believe I'd squeeze every cycle out of the GPU. But if I'm figuring tax on a cup of coffee, or the total of a chart on a web site, efficiency isn't nearly as important as provable correctness.
Lest you think I'm trying to defend the stupid walled gardens of iOS and their ilk's practices of constraining UIs and simpleton features, I'm not. I do think that there needs to be a mix, however. To use your iPhone rant, first remember that the iPhone is sold to completely average people, therefore, a simple UI is the primary requirement. (In other words the "dumbwagon" must be the default.) Furthermore, it should be restricted so that Joe Average can't accidentally screw it up to the point where it's impossible for him to recover to the dumbwagon state. Beyond that, however, everything else should be possible - there should be advanced configurations, user scripting, compilers, all that stuff that makes a computer do what I want. (And that's why I hate Apple.)
We may never get a dinosaur theme park, but we've got a decent shot at a carousel full of ancient horses, saber-tooth tigers, and wooly mammoths. What could possibly go wrong?
Sorry, I don't have cameras, so I don't know how they work through Vera. From what I understand, if you have a compatible IP camera system that can be remotely controlled, you could play it back through Vera. I also know there's only a certain subset of cameras that work through Vera - and you can find them on their wiki. But I know Vera doesn't do the actual video compression or storage - that's part of your camera/video system.
My energy company wants me to sign up for a smart thermostat where they can remotely change my temperature if they decide I should be using less energy -- and I sure as hell wouldn't want that.
And why is that?
Here's the deal: the world is adding a lot of homes and factories to the existing power grid, but they're not building a lot of new electrical plants. Nobody wants coal stacks near their house, nobody wants nuclear power in their back yard, nobody's going to dam another valley and kill a bunch of endangered owls, yet everyone in those new homes and factories still expect the lights to come on when they flip a switch. The grid is not only close to capacity, it's frequently at capacity. Instead of causing rolling blackouts, your power company probably buys supplemental peak electricity from factories and data centers that have large backup generators - but that emergency electricity costs anywhere from 10X - 50X the price of their existing plants, and burns expensive diesel fuel or natural gas.
The power companies would be happy to give you regular electricity at lower rates if they could charge you peak rates for consuming extra electricity during peak times. I say this because that's exactly what mine does. By agreeing to allow them to shut off the power to my heat pump for up to 40 minutes per hour during peak demand, I pay about $0.05/kWh for all the energy it uses year round. Without their demand sharing program, it would cost me at least $0.12/kWh no matter when I use it. Between me and the other members of my co-op signing up for this program, we have saved enough peak generating capacity to defer the construction of a new power plant by 10 years, so our overall rates have remained nice and low. I haven't seen an electricity price increase in 10 years. (Yes, electric co-ops are awesome and your giant energy conglomerate sucks.)
So what if the house gets a few degrees warmer on about 5 afternoons out of the year? Cooperation is worth it.
And regarding security, our load controller is a simple FM receiver that operates a relay. When it gets a "sharing request", it picks its own time window and shuts the pump to the compressor off for a random 40 minutes out of each hour. The thermostat is calling for cooling, the HVAC system is running the fans and it thinks it's turned the compressor on, but nothing cool actually happens. The relay is the only interface to my house, and it is wired directly into the compressor. There is no other interconnection with any home systems, no back channel through which a hacker could inject a rogue FM signal to unlock my doors, or disable my alarm system, or shut off my freezer and make my frozen foods all melty.
Slashdot Mirror
Because they're all integrated. Your car's radar can detect that the vehicle in front of you has suddenly hit the brakes, it can sound an alarm and blink a light on the windshield warning you of a road hazard immediately ahead, the engine telemetry can talk to your ABS braking systems telling them that the car is still moving even though the brakes have locked up, your crash sensors can detect an accident, your seat belt pre-tensioners and airbag deployment systems help protect the cabin occupants in case of an accident, your entertainment system can tell your cell phone to call a number, and your telemetry system records the events. Tying them all together permits your car to help you avoid accidents, protect you in case of an impact, call an emergency services number in the event of a crash, and can even help prove to a court that you were traveling only 5 MPH and had applied the brakes two seconds before you were struck.
There are safety designs in place. The different systems tie to the CAN bus through a fairly simple and robust chip that implements the protocols, which helps insulate and isolate a faulty device from overrunning the bus. There are often multiple CAN buses in a car, with engine management and safety being isolated from cabin entertainment systems. The CAN bus protocol has a priority mechanism, where lower numbered devices take priority over higher number devices - safety systems, such as ABS, crash detection and airbag deployment, are the lowest numbers, security systems like door locks have higher numbers, and the whiz-bang gadgetry of your stereo has the highest numbers.
Furthermore, your ABS system is an active driver assistance system, but it's not your means of braking. If it fails, the hydraulics still connect your brake pedals to your wheels, and you can still maintain control of the car. The airbags are just one component of an overall safety package, so if they fail, the seat belt pre-tensioners might still work. Even if the pre-tensioners also fail, the seat belts themselves still offer protection. The steering wheel is designed to collapse in the event you hit it with your body. The body is designed with crumple zones to absorb impacts.
What they've done is to combine these pieces that have known failure rates of one per tens or hundreds of millions of miles driven, and used them to protect you in the case of a serious accident, which they know happens once per hundred thousand miles driven. The chances of the systems working together to keep you safer are much higher than the chances that they'll all fail at the moment you need them the most.
In-Car Electronics (ICE). Control console. Dash GUI. Dash interface. Driver interface. Carputer (I threw that one in to go with infotainment. :-) Make something up.
Ford's SYNC is bad, but MyTouch is abysmal. Not only do you have a touch screen, but the fixed controls are touch sensitive. Reaching for them blindly is the same as activating them. And they reportedly don't work with gloves, which may not be a problem in San Diego, but here in Minnesota that's a killer.
Older cars used to have a fairly standard interface for the in-dash radios, because they were simply radios. But with factory installed sound systems featuring a dozen independent speakers, trunk-mounted amplifiers, integrated climate controls, navigation systems, and all tied into the car's CAN bus, replacing them with an aftermarket product is much less of an option these days. On many of these tightly integrated vehicles, I fear they may never be upgradable.
Take a look at what the "local maniac" did to install an iPad mini in the dashboard of his truck: http://hackaday.com/2013/01/02/a-very-dash-ing-ipad-mini/
Of course, not every stereo installer is going to custom sculpt a trim ring for each stereo they install. But when they do, the results can be impressive.
What amazes me is that companies like Ford refuse to acknowledge this. To me, it's incredible that they can be so stupidly focused on trying to make a product that can never be made to work properly, because humans don't work that way.
And it's not like they aren't being told this repeatedly. Consumer Reports states in every article featuring a Ford product that has their "Ford MyTouch" system that the car lost somewhere between 4 and 8 points on its overall score due to the crappy interface. And in many cases those points would take the vehicle from the middle or bottom of their grouping to the top of their category. This has been going on for every MyTouch equipped vehicle they have released since the 2012 model year.
After looking at this carefully, the conclusion I have come to is they must have some hyper-egotistical VP of infotainment who has an MBA or marketing degree but no engineering background, and he has deemed by fiat that "touch screens are what people buy on their phones, make it happen on the dashboard", ignoring the advice of his safety engineers and human factors team. Microsoft was overjoyed to sell them their misnamed SYNC system (it actually syncs with nothing) as a base product, which they then had developed by some team who had no idea they were writing a car interface, and who still think popup "Are you sure you want to exit?" dialogs are appropriate for a vehicle. I wouldn't be surprised if their next release has the Windows 8 interface, complete with animated tiles trying to tell the driver that he has a new Facebook follower, three emails, and a coupon offer for a free trial of Angry Birds.
If Ford can't change under pressure from engineers and consumers, I expect that there will be several lawsuits from the victims of distracted drivers. And that's a tragedy.
"Consider what they could be doing today if they managed to mass produce 4096 bit quantum computers. They could be intercepting all SSL traffic in real time."
Or they could just have a blanket arrangement with one or more certificate authorities to generate signed and trusted keys for any domain on request...
Why "OR"? The NSA is really more of an "AND" agency. I think we can assume that anything and everything that could be done to intercept traffic is being attempted at some level or another.
We have India offices staffed with employee developers, not contractors. And that really is the best thing about our organization - we're all in it together, so there isn't an us-versus-them mentality. It's convenient to hold contractors at arm's length, and blame them when things go awry, and it's easy to say "let's end this contract." But it's very hard when you're all reporting to the same boss. That's had a lot to do with our success.
And you're absolutely right about the time difference being an issue. But you can make it work to a degree.
They've shifted their working times to start later in the morning and end later in the evening, and we have shifted our mornings to accommodate earlier meetings. We can get two hours of overlap every day with few problems, and depending on the situation we can get an additional couple of hours. It's enough to have hand-off kinds of meetings, and to discuss a project or specific problem, but not enough to work with them in a coaching, mentoring, or close partnership kind of role. That takes expensive travel, so it doesn't happen as much as either side would like. But when it does, it's great. I have some very good friends who just happen to live on the other end of a long plane ride, and I appreciate that globalization introduced us.
You may assume that the knowledge gap between the NSA and civilian cryptographers has closed, but since we don't know their capabilities, that's only a guess.
The few things we do see coming from them look very carefully chosen to meet the public expectations. See Bruce Schneier's commentary on Skipjack. One thing we can be reasonably certain of is they never reveal all their cards when interacting with civilians.
The gap could have widened as easily as it could have been closed. The NSA hires a lot of very bright mathematicians, as well as physicists, engineers, and a lot of other skilled folk. They have proven themselves capable of not only researching novel algorithms, but of creating novel hardware on which to run it. Consider what they could be doing today if they managed to mass produce 4096 bit quantum computers. They could be intercepting all SSL traffic in real time.
That's the thing about a secret organization. We don't know their capabilities, and we may never know. We only know it's not safe to rely on an assumption that we've caught up to them.
Ballmer post? Guess we'll be needing these:
Developers. Developers. Developers. Developers. Developers. Developers. Developers. Developers. Developers. Developers.
Don't forget: Chair! Chair!
Blocking the URLs is only one of its mechanisms. The lack of a JavaScript switch hasn't hampered its inline suppression capabilities, either. Since I normally run it trusting scripts originating from the site's domain, that isn't as much of an issue for me.
You apparently outsource your "Comment Subject" writing to the Caribbean, Jamaica, from the looks of it, or maybe Minnesota.
It's from an old South Park episode. While I wouldn't exactly call someone uncultured for not knowing that, I also wouldn't call someone on it who is obviously mocking the position it represents.
Average quality of a government systems administrator - Priceless
Is that an advertising joke, or a division by zero error? :-)
I know some great offshore developers, and I also know some American developers that aren't worth their salt. Each assessment needs to be made at a personal level; you can't make a valid blanket stereotyped claim that fits everyone.
What I see causing most of the poor quality work is developers who are suffering from idiotic corporate practices, policies, and rules. "All developers shall submit their UML drawings to the UML Governance Board, and have them approved by no less than three board members, thus ensuring quality software will be developed from them." Very few developers (onshore or offshore) are successful producing quality software in such an environment, and it's especially tough for contractors who feel constrained to follow the letter of the rules without question. Now apply that constraint to a culture that reinforces the idea to accept work tasks without question anyway, and the lack of feedback pretty much ensures you'll get unexpected results.
Take the chains off, though, and you can get spectacular results from good people. You'll never get those results from bad developers, regardless of which landmass they live on.
Farm subsidies are just one of many form of protectionism.
Protectionism isn't simply import/export tariffs. It's any government policy that works to either favor internal production or hinder the import of externally produced goods and services; more broadly, it's any government policy that impacts free market capitalism. In other words, it's a word applied whenever the government decides to spend money in one area and not another, and is generally used in a derogatory fashion by the people who were negatively impacted. California dairy farmers cry protectionism when Wisconsin dairy farmers get higher subsidies than they do. Nike claims protectionism when New Balance gets the contract for military footwear. The list is endless.
Does this break noscript functionality as well? That would be massively unappealing.
No. NoScript is a plug-in that refuses to load undesirable JavaScript references. They are stopped before they get into your browser.
I'd say to look for more of this mistreatment and abuse.
I doubt anyone in authority (except for some really stupid cops) believes the kid is actually a threat. What the rest of them are trying to do is hold him up as a warning example to all other kids "don't make school shooting jokes or we will jail your ass for as long as we like."
The authorities in Austin are forgetting two crucial element of this whole process, though. The first is that teenage boys are capable of learning this lesson and applying rational thought to their behaviors - the number of teen drunk drivers and teens killed by texting-while-driving proves this is a futile exercise. The second is that we all have the right to free speech, and that what they're doing is far more illegal than what the kid did; at least one of these a-holes needs to end up in jail for abusing the child's rights.
"He'lloo. Mi na'ame izzz Brian. Havv yyeww *click click* t'reied t'urning it ovv ant b'ack on a'gain?"
Philistine.
Consider it from a testability standpoint. If a module is externally testable and provable, and it has a good name that defines what it does, it's a good place to draw the line. Writing testable code generally means making it readable and reusable.
The other side of that is that a large, complex piece of code is hard to test. Having a complexity metric of 15 means that trying to go through all its paths could be impractical. If it's broken into smaller methods that each encapsulate a smaller idea of the complex whole, it becomes simpler and more readable - and more testable.
I agree LoC is a crappy metric, but complexity gets closer to the heart of the problem. The higher the complexity, the less likely you are to have 100% test coverage - and that leaves room for bugs, misinterpretation, and a method that probably won't be reused.
But you forget you also have to walk back to your desk.. At that point, you have two usages of a pathing algorithm.. Which means you're repeating code, which means that using a function to enable code re-use instead makes sense. I'm hardly an advocate for complex functions (most of my code are 1 or 2 liners), but there are times when you simply cannot express something concisely in a short function, and the answer to that is *not* to artificially reduce it into code that does nothing but resides in a different location.
I think you missed his point that "heatLunch()" was far more readable than "stand/turn left/walk 4 steps...". If you were defining lunch activities, you might have a lunchtime() event that has two methods: eatLunch() and readSlashdot(). eatLunch() might be made up walkToKitchen(), prepareLunch(), eatLunch(), and goBack(). walkToKitchen() could be start=getLocation(); path=navigateFromTo(start, kitchen); walk(path). prepareLunch() could be made of of cookLunch() and serveLunch(), and so on. Each task is progressively built up from simpler subtasks.
At any point you can look at the small contents of a routine and understand what it's doing at that context, but you don't necessarily need to know the larger context you're a part of. Reading the contents of walkToKitchen() doesn't imply I have to know anything about the lunchtime() event, certainly no more than seeing me walking proves that it's lunchtime. But all together, each of those small, simple steps add up to lunchtime.
The efficiency of a system can not simply be measured by CPU cycles. It all depends on where your costs are. Efficiency has to be measured by money.
If your highest costs are in runtime efficiency, then yes, you need efficient code. But if your highest costs are in end-user time spent entering data, usability beats efficiency. If your highest costs are driven by software engineering practices, such as testability, reliability, supportability, frequent deployments, etc., then readability becomes far more important than efficiency.
The usability argument works like this: if I have to pay a barrista $10 an hour to touch 20 buttons just to place an order for coffee, and the user time per button press is 3 seconds while the system time per button is 8 milliseconds or less, the efficiency of the code is almost irrelevant. My development investment is best spent in reducing the number of button presses. If a fancy GUI and a magical "do what I want" button reduces the 20 button touches to 10, I can save 30 seconds of labor per cup of coffee. If adding that fancy GUI increases the system time from 8 milliseconds to 30 milliseconds per button press, I haven't actually incurred any additional labor costs because the system is still faster than an average human's response time (maybe not in a highly caffeinated coffee shop, but it's still far less important than saving even a single button press.)
I've found that in most business applications user time is the largest expense, by a very wide margin.
If libraries of tested proven code are cheaper than hand written assembler, I don't want to pay a developer to replicate that work, even if it would be theoretically more efficient - unless the program that they're working on has efficiency as the most important goal. If I was developing an algorithm for slinging polygons at a graphics card, you better believe I'd squeeze every cycle out of the GPU. But if I'm figuring tax on a cup of coffee, or the total of a chart on a web site, efficiency isn't nearly as important as provable correctness.
Lest you think I'm trying to defend the stupid walled gardens of iOS and their ilk's practices of constraining UIs and simpleton features, I'm not. I do think that there needs to be a mix, however. To use your iPhone rant, first remember that the iPhone is sold to completely average people, therefore, a simple UI is the primary requirement. (In other words the "dumbwagon" must be the default.) Furthermore, it should be restricted so that Joe Average can't accidentally screw it up to the point where it's impossible for him to recover to the dumbwagon state. Beyond that, however, everything else should be possible - there should be advanced configurations, user scripting, compilers, all that stuff that makes a computer do what I want. (And that's why I hate Apple.)
We may never get a dinosaur theme park, but we've got a decent shot at a carousel full of ancient horses, saber-tooth tigers, and wooly mammoths. What could possibly go wrong?
Sorry, I don't have cameras, so I don't know how they work through Vera. From what I understand, if you have a compatible IP camera system that can be remotely controlled, you could play it back through Vera. I also know there's only a certain subset of cameras that work through Vera - and you can find them on their wiki. But I know Vera doesn't do the actual video compression or storage - that's part of your camera/video system.
My energy company wants me to sign up for a smart thermostat where they can remotely change my temperature if they decide I should be using less energy -- and I sure as hell wouldn't want that.
And why is that?
Here's the deal: the world is adding a lot of homes and factories to the existing power grid, but they're not building a lot of new electrical plants. Nobody wants coal stacks near their house, nobody wants nuclear power in their back yard, nobody's going to dam another valley and kill a bunch of endangered owls, yet everyone in those new homes and factories still expect the lights to come on when they flip a switch. The grid is not only close to capacity, it's frequently at capacity. Instead of causing rolling blackouts, your power company probably buys supplemental peak electricity from factories and data centers that have large backup generators - but that emergency electricity costs anywhere from 10X - 50X the price of their existing plants, and burns expensive diesel fuel or natural gas.
The power companies would be happy to give you regular electricity at lower rates if they could charge you peak rates for consuming extra electricity during peak times. I say this because that's exactly what mine does. By agreeing to allow them to shut off the power to my heat pump for up to 40 minutes per hour during peak demand, I pay about $0.05/kWh for all the energy it uses year round. Without their demand sharing program, it would cost me at least $0.12/kWh no matter when I use it. Between me and the other members of my co-op signing up for this program, we have saved enough peak generating capacity to defer the construction of a new power plant by 10 years, so our overall rates have remained nice and low. I haven't seen an electricity price increase in 10 years. (Yes, electric co-ops are awesome and your giant energy conglomerate sucks.)
So what if the house gets a few degrees warmer on about 5 afternoons out of the year? Cooperation is worth it.
And regarding security, our load controller is a simple FM receiver that operates a relay. When it gets a "sharing request", it picks its own time window and shuts the pump to the compressor off for a random 40 minutes out of each hour. The thermostat is calling for cooling, the HVAC system is running the fans and it thinks it's turned the compressor on, but nothing cool actually happens. The relay is the only interface to my house, and it is wired directly into the compressor. There is no other interconnection with any home systems, no back channel through which a hacker could inject a rogue FM signal to unlock my doors, or disable my alarm system, or shut off my freezer and make my frozen foods all melty.