"When the deadline comes, would you rather the project be incomplete but ready for delivery, or would you rather push back delivery in favor of complete and correct software?"
Yes, this is what I was trying to get at in my post. And I'm not sure I've ever worked on any project where there wasn't some level of "incompleteness" when we reached the deadline. In a well planned project where things go right, the "incompleteness" might be things like, "we didn't test it as well as we would have liked" or "we didn't implement a feature that seemed like it'd be nice to have". And then beyond the original scope, there's always more that could have been done to perfect things.
In the end, meeting deadlines always comes down to priorities. The priority might mean, "I told the client I would complete set requirements by the deadline, so I will technically meet those requirements by doing a crappy half-assed job." But then that will often make your client less happy than being able to say, "The project is a little over-budget and past the deadline, but we got things done correctly." It depends on the project and on the client.
And as you point out, it also depends on how good you are at communicating these things in an appropriate way at an appropriate time. If you tell a client 2 weeks into a 6 month project, "It looks like we're going to end up missing the 6 month deadline, so let's set it for 8 months instead," you might get a much happier client than if you deliver the same message the night before the deadline.
It doesn't matter whether or not a project "can" be set to a specific schedule... a client will still expect a deliverable on date X.... and if there isn't, well... the client will simply stop paying you...
Yeah, but you should still know what the real priorities are. Like I said, if the project requirements are "have A, B, and C deliverables complete by date X below a budget of $Y," then you should be sure to try to understand which of those things are more important than others. Is A more important than C? Is it more important to be done before date X, or that B is delivered as promised? If it turns out you have to spend $Z over $Y to complete C on time, is that going to be acceptable? Maybe if you can't deliver B on time, you should just cut your losses and abort the whole project, but A is completely expendable.
In my opinion, understanding each of these things is usually more important than simply setting a schedule. Some projects have inviolable requirements, schedules, and budgets, but those are really pretty rare. Mostly, you have bad program managers acting as though schedules are inviolable because they don't understand the projects they're running.
I wish people would understand that project schedules should *only* be considered guesses and estimates. Take the time you think it will take, and then take a step back and ask yourself, "No really, how long will it take?" When you get a number, take another step back and ask yourself, "No, *really*, when a bunch of things go wrong and it takes longer than I expect, how long will it take?" And then treat that time frame as a best-case scenario.
Part of the problem is that many projects can not be set to a specific schedule. The real answer is usually "it depends". How long will it take to build a new website? Well it depends on what unexpected hurdles we run into. It depends on how many features you want to add after we begin. It depends on how many revisions we go through.
When people ask me to set a firm deadline, I'm always tempted to ask them, vaguely, "When we don't meet that deadline, what do you want me to sacrifice?" Any deadline can be met if you sacrifice enough of the project requirements. So if we're coming up on a deadline, would you rather I miss the deadline or that I sacrifice some of the requirements? That is, let's say you want a website running with features X, Y, and Z, and we have a deadline of June 1st. The question isn't whether I can meet the deadline of June 1st. The question is, on May 31st, when feature Z isn't ready (there will be some feature set "Z" that isn't ready), do you want to go ahead and launch the site anyway? Or is Z worth holding up the launch?
In other words: project managers should should focus on priorities rather than schedule. "Being on schedule" and "being within budget" are just two more features that need to be prioritized within the set of features that a project is trying to meet.
I'll tell you, this seems to me to be a very interesting development. I think the next step they should be looking at is to develop the ability to purposefully implement partial replicas at different sites, allowing for a kind of distributed filesystem.
For example, lets say I set up 30 servers around the world, each with this Bitorrent Sync system set up, each containing 20 TB of data. Now in order for Bittorrent to work, I don't think I need each of those servers to have a full copy of every file. Imagine I could say, "Make sure than any one block is automatically stored on at least 6 servers". Now I have 100 TB of redundant storage online accessible via the bittorrent protocol. Then I could have different individual clients set to only sync a certain subset of that storage.
If you have symmetric up/down, then there would be no speed advantage.
Well I suppose it still depends. Imagine you have 20 computers staying in sync, all through symmetric 10mbps connections, then you add another. Even if the additional computer only has a 10Mbps connection, meaning you may not get the download faster than simply downloading from one source, you could still see a benefit from distributing the load among the other 20 computers. So instead of saturating the upload pipe for one computer, you're a minor.5mbps upload on each.
The entropy-maximization isn't about complex, "long-term" planning for "future states" on a how-to-survive-to-next-year, or even how-to-survive-to-next-hour, time scale.
So then am I wrong if that makes me suspicious that it won't model behavior very well in general? A model that doesn't account for decisions that sacrifice possible "states" in the next 30 seconds for some benefit 3 minutes from now? I wouldn't deny that many kinds of behavior are very short-sighted, but the more we talk about it, the more deficient it seems.
It's a model for generating short-term actions (e.g. "move towards the stick and grab it; push the stick towards the trapped food)
Now if the crow moves towards the stick to "maximize states" and then grabs the sticks to "maximize states", then why aren't crows always moving towards sticks and grabbing them, even when there's no trapped food?
Well most modern models of intelligence/consciousness (at least that I've read about or heard about) imply that it's some kind of emergent property of complex heuristics. Now that's a vague explanation, but there seems to be a consensus that it's something like that.
I don't understand the "generic physics-motivated" model, but I'd imagine it would run into a lot of shortcomings. Crows maximize the number of future states available? It seems like that might be roughly true in some circumstances without being at all causal. Do the number of future states increase when an organism survives for longer? Then is it "maximizing states" or "maximizing survival"?
And how do you account for mistakes and misunderstandings? How do you account for instances of poor decision-making? Behavior is pretty complex.
To me, this at least seems less bonkers than (now mostly outdated) approaches that tend towards assuming something that looks like formal syllogistic symbolic logic generates "smart" behaviors.
I guess so, but I don't know if the "experts" in psychology or AI think that intelligence is generated through logical syllogisms. So I don't necessarily doubt that crows are using some kind of heuristics when they decide to use a stick, but I have some doubts about whether the heuristics are so simple that they can be modelled accurately without considering the biology and psychology of the crow itself.
Many cognitive models might approach this by assuming the crow has a big table of "knowledge" that it can logically manipulate to deduce an answer... This paper, however, proposes a much more general and simple model... the crow lives by the rule "I'll do whatever will maximize the number of different world states my world can be in 5 seconds from now." By this principle, the crow can reach a lot more states if it can move the stick... This provides a very general mechanism for cognition driving a wide variety of behaviors, that doesn't require the thinking critter to have a giant "knowledge bank" from which to calculate complicated chains of logic before acting.
There may be an interesting insight in there, but it doesn't seem to me to solve the problem. It seems to me that you haven't changed the mechanism, but rather the motivation for acting-- from "hunger" to "maximizing states". Actually, I'm not even sure you've changed the motivation, but rather reframed it.
It seems like you haven't removed the need for a "knowledge bank" or "chain of logic", unless you've described the mechanism for how "maximized future states" is converted into "crow behavior". Does the crow "know" which behavior will result in maximizing his states, or is it achieved in some other way?
Sociobiologists come up with plausible and reasonable sounding theories for many of these, but most of them remain just guesswork if there isn't hard data and hard mathematical modeling
I find this to be a good reason why we should bring back "natural philosophy" (and other philosophical branches) as fields which are not considered "science". Right now, there's such a push to apply science to philosophy or to make philosophy a subset of science, or just as bad-- to argue that philosophy is obsolete now that we have science.
In truth, there's a lot of room for people to be generating concepts and ideas independent of determining how to test those ideas, or even whether it makes sense to try to test them. Many of the things we currently call "science" don't lend themselves to the scientific process very well. They don't make for easy controlled experiments, and are inherently going to be guesswork without hard data. In fields like psychology and economics, even when we have "hard data" and "mathematical modeling", there's still too much interpretation to be thrown into the same group as physics, chemistry, and biology.
For example, it doesn't make sense to try and split the coding into a "creative coder" (who knows nothing about programming) and an "implementation coder" who turns the creative's ideas into actual code. The creative would toss out nonsensical ideas (like "instead of using vectors, why not use genetic algorithms?"), and then the implementer would have to explain why all those ideas are silly... or else they would just have to ignore the creative type and simply code something that makes sense.
But couldn't there be someone who says, "I want you to write code that does this..." and have someone else write the code? I'm not a coder, but I know I've been in situations where I worked out the logic and math of a problem, handed off some pseudo-code to a real programmer, and said, "Turn this into real code and optimize it." I'm not enough of a programmer to know whether the code that resulted was ideal, but it certainly worked as intended. I've also worked with a programmer and said, "I want a program that optimizes for this..." and he came up with the math to do that all on his own.
Now I think it's good to have knowledge across a lot of disciplines, but I don't see what the problem is with a little teamwork. It seems just as likely to me that you'll get errors from people making non-mathematical assumptions about fields they don't understand. Like you could be a medial researcher and brilliant statistician studying a new anti-depressant and misread the data because you don't understand psychology sufficiently to be measuring the right indicator. So why shouldn't we have people from different areas and fields working together?
This story [computerworld.com] indicates that "unusual events" happen a few times a year
"A few times a year" is pretty common in my book. And let's not forget that even if the outage is precipitated by a normal holiday, that doesn't preclude the possibility that people would be having emergencies during that time, and be prevented from calling for help.
Everything I've read implies that expanding them to handle rare emergency loads costs a lot and there just isn't a good case for spending that kind of money.
This is exactly what I find to be dishonest about the way you talk, right here: "there just isn't a good case". Obviously there's a good case. It could save lives. Not just "could", but "almost certainly would". If it's too expensive to justify that should be a painful unfortunate reality, and not something to be dismissed as though there's just no argument to be had.
Emergency crews, firefighters, and police, the bulk of the official response to disaster and such, for example, rely on radio not on cell phones.
Right, so you're claiming that telephones are unimportant during an emergency.
These things are rare. We don't have to speculate, we just look at the occurrence of actual large scale emergencies that overwhelm the local cell network infrastructure.
How rare? I ask because I'm pretty sure you're just making this up. And what about other unrelated things that happen during an emergency? Someone bombs Boston, and what about a robbery that happens at the same time? Any one scenario is rare, but when you add up all the various possible rare scanarios, are they really so unrealistic?
The world has had earthquakes, tsunami, landslides, riots, explosions and fires, and power outages and such. These routinely take out cell network infrastructure.
Those aren't the only emergencies that overwhelm cellphone networks, and those events don't always damage cellphone infrastructure so as to make the infrastructure useless regardless of traffic. If you really want to argue, provide some examples and statistics to prove your point. Otherwise, stop claiming weird counter-intuitive claims.
and yet, we might have to shut that network down when it's most needed.
Wait, so are you admitting here that cell phone infrastructure is needed during emergencies?
I note that wasn't what was said. If we're going to be "clear" about this, here's what was originally said:
And then you quote a bunch of stuff as though you hadn't really read any of it. First, I wasn't saying you specifically said that, but you are among many people making statements similar to that. You claim you never said, "nobody needs a telephone during an emergency." and yet you quote yourself saying, "We don't rely on the cell phone network in an emergency."
That's a very contrived situation.
It's one example of how a cell phone might help you in an emergency. That situation might be rare, but if you start aggregating all of the possible rare emergency situations where a cell phone might be helpful, I think you'll find that it's probably not such a rare thing. Plus, it's not much more contrived to say, "maybe you'd be injured by conscious and emergency services wouldn't know where to look for you," than to say, "well maybe emergency services would find you if you banged on something." They're trained to listen for noise, not because they'll necessarily be able to find anyone making noise, but because *they have nothing else to go on*.
Anyway, my whole point, over and over again, is if you really are ok with the situation, then fine. Let's agree that it's not worth paying for a robust cell phone network that can function during emergencies. Let's make that very clear with everyone in the society, that you can't depend on cell phones in an emergency. But don't be evasive in our wording and pretend that having our telecommunications network fail during emergencies won't ever cost some lives. Let's just admit that we're saying, "saving those lives is too expensive."
These disasters include a considerable subset which damages or destroys the cell phone network.
First, that seems like a big assumption with no evidence behind it. Talk about a contrived situation. Yes, I suppose a nuclear bomb would knock out cell phones, but there are many kinds of emergency situations that won't knock out the cell phone network. And again, you're saying "There's no point in mitigating some risks because there will still be other risks."
Yet another risk which I didn't address is what happens when someone sets off bombs via cell phone triggers. Now, you might have to make a hard choice between keeping the cell phone network (and related emergency services) up and losing more lives due to bombs which haven't been triggered yet.
That's a totally different issue. Regardless of whether the cell phone network can handle capacity during an emergency, they could still shut down networks if they suspect it's going to be triggered by a cell phone. It's not really what we're talking about here.
I really don't see the point of arguing over this.
Says the guy who continues to argue over this despite not having good arguments.
Unfortunately some of the people replying to you are saying, essentially, "There are tech people on the market, but they're either under-qualified or they expect too much money." I say 'unfortunately' because this sentiment misses the point.
By their own argument, the problem isn't that there are no candidates, but that the candidates are expecting 'too much money'. While they might think their expectations are unrealistic, if you really can't find someone suitable for cheaper, then via supply/demand, that's the going rate. So essentially the salaries they're requesting are probably appropriate given that their skills are in high demand and there's a limited supply, but employers want so change the supply/demand balance by flooding the market with cheap foreign labor, thereby driving down programmers' wages.
Now we can argue about whether or not that's a fair thing to do, but let's not pretend it's about a lack of skilled workers. It's about businesses wanting to cut labor costs.
Yeah, I find myself not minding this so much. I do think electronic records should somehow "sunset" at some point, even if it's after a few years, for various reasons. However, I don't see what the big deal is whether Apple retains the data for 1 month vs. 6 months vs. 2 years.
When I used Siri for the first time and realized it was sending my questions to a datacenter somewhere, I had an immediate reaction of "that's a bit creepy and disconcerting." But once the data is sent out to the datacenter for processing, you've already opened the door for the data to be misused. Once you assume that the data will be stored for some amount of time, you increase the chances for the data to be misused. But if you extend the time that the data is stored for a for months or a year, I don't feel like you're greatly increasing your exposure.
What holding on the data actually does is it gives Apple some time to process and analyze the data, improving the speech recognition and heuristic models. I'd expect them to want to keep it for a couple years, especially since Siri is new and they're probably still developing their methods for analyzing the data. In this sort of situation, having more data means being able to create a more accurate analysis.
Scarcity: There are scarce things that are not valuable because people don't want it.
Conductivity: Then why not copper?
High Mass: So heavy things are valuable now?
Low melting point: Then why not chocolate?
Imperishability: Not such a huge issue in the modern era, when we can preserve many materials and remove oxidation from lots of metals.
Gold is ultimately as valuable as it is because it has a history of being "Ooooo! Shiny!" Because of we all agree that gold is awesome and shiny, be agree on a set price through a process not too different from setting the price of fiat currency. If everyone suddenly agreed that gold was no longer pretty, the value would implode just like fiat currency.
I get the sense that you think you're arguing with me, but I don't see how you are.
if we had a pill that would completely wipe out the flu in your body with no adverse side effects, I think we would use that instead of a decongestant. Sure, we treat the symptoms as a stopgap or when we can't fix the root cause but ultimately, we fix the root cause whenever we're able.
That's essentially the reason that people who favor affirmative action hold that position. We don't have a pill that can completely wipe out cultural bias, so we treat the symptoms as a stopgap, hopefully allowing these biases to "heal naturally".
Sucks to be you then. I still don't get why these contrived scenarios are supposed to justify spending a lot of money beefing up cell phone coverage. It is rare for an activity to be completely absent of benefit for anyone.
My whole point, as stated several times, is that we should be honest about the decision we're making. If you want to say, "It's not worth the money to have our telephone infrastructure robust enough to continue to operate during an emergency," then I'm not convinced that you're wrong.
However, let's be clear about it. Let's not say, "Well, emergencies never really happen and nobody needs a telephone during an emergency." That's dishonest. To give an alternate example, if you said, "It's not worth lowering the highway speed limit to 25 miles per hour. Sure, having it as high as 55 mph will mean more people die in car accidents each year, but preventing those deaths is not worth the economic and social impact of slowing car travel so much," then I wouldn't really have an argument. But don't try to argue, "Well going 25 mph is just as safe and car crashes never really happen anyway."
No. I can't see that analogy. I think it's more like saying that putting a lot of money into beefing up a cell phone network still has the major problem that there are a variety of disasters that could take down the cell network anyway.
Right, hence the analogy. "There's no point in mitigating some risks because there will still be other risks." It's a bad argument. Risks are additive, and so having multiple different kinds of risks makes it even more important to mitigate risk where possible.
You're saying the problem is with people that have identified a potential root cause, rather than just trying to treat the symptoms? I sure hope you're not a doctor.
We often treat symptoms rather than the root cause. If you're seriously injured, they might give you a pain reliever and something to reduce swelling. If have the flu, they might recommend a fever reducer and decongestant/expectorant. If you have lung cancer, they don't try to go back in time to prevent you from smoking. The focus is generally on reducing the symptom of "death".
Slashdot Mirror
"When the deadline comes, would you rather the project be incomplete but ready for delivery, or would you rather push back delivery in favor of complete and correct software?"
Yes, this is what I was trying to get at in my post. And I'm not sure I've ever worked on any project where there wasn't some level of "incompleteness" when we reached the deadline. In a well planned project where things go right, the "incompleteness" might be things like, "we didn't test it as well as we would have liked" or "we didn't implement a feature that seemed like it'd be nice to have". And then beyond the original scope, there's always more that could have been done to perfect things.
In the end, meeting deadlines always comes down to priorities. The priority might mean, "I told the client I would complete set requirements by the deadline, so I will technically meet those requirements by doing a crappy half-assed job." But then that will often make your client less happy than being able to say, "The project is a little over-budget and past the deadline, but we got things done correctly." It depends on the project and on the client.
And as you point out, it also depends on how good you are at communicating these things in an appropriate way at an appropriate time. If you tell a client 2 weeks into a 6 month project, "It looks like we're going to end up missing the 6 month deadline, so let's set it for 8 months instead," you might get a much happier client than if you deliver the same message the night before the deadline.
It doesn't matter whether or not a project "can" be set to a specific schedule... a client will still expect a deliverable on date X.... and if there isn't, well... the client will simply stop paying you...
Yeah, but you should still know what the real priorities are. Like I said, if the project requirements are "have A, B, and C deliverables complete by date X below a budget of $Y," then you should be sure to try to understand which of those things are more important than others. Is A more important than C? Is it more important to be done before date X, or that B is delivered as promised? If it turns out you have to spend $Z over $Y to complete C on time, is that going to be acceptable? Maybe if you can't deliver B on time, you should just cut your losses and abort the whole project, but A is completely expendable.
In my opinion, understanding each of these things is usually more important than simply setting a schedule. Some projects have inviolable requirements, schedules, and budgets, but those are really pretty rare. Mostly, you have bad program managers acting as though schedules are inviolable because they don't understand the projects they're running.
I wish people would understand that project schedules should *only* be considered guesses and estimates. Take the time you think it will take, and then take a step back and ask yourself, "No really, how long will it take?" When you get a number, take another step back and ask yourself, "No, *really*, when a bunch of things go wrong and it takes longer than I expect, how long will it take?" And then treat that time frame as a best-case scenario.
Part of the problem is that many projects can not be set to a specific schedule. The real answer is usually "it depends". How long will it take to build a new website? Well it depends on what unexpected hurdles we run into. It depends on how many features you want to add after we begin. It depends on how many revisions we go through.
When people ask me to set a firm deadline, I'm always tempted to ask them, vaguely, "When we don't meet that deadline, what do you want me to sacrifice?" Any deadline can be met if you sacrifice enough of the project requirements. So if we're coming up on a deadline, would you rather I miss the deadline or that I sacrifice some of the requirements? That is, let's say you want a website running with features X, Y, and Z, and we have a deadline of June 1st. The question isn't whether I can meet the deadline of June 1st. The question is, on May 31st, when feature Z isn't ready (there will be some feature set "Z" that isn't ready), do you want to go ahead and launch the site anyway? Or is Z worth holding up the launch?
In other words: project managers should should focus on priorities rather than schedule. "Being on schedule" and "being within budget" are just two more features that need to be prioritized within the set of features that a project is trying to meet.
I'll tell you, this seems to me to be a very interesting development. I think the next step they should be looking at is to develop the ability to purposefully implement partial replicas at different sites, allowing for a kind of distributed filesystem.
For example, lets say I set up 30 servers around the world, each with this Bitorrent Sync system set up, each containing 20 TB of data. Now in order for Bittorrent to work, I don't think I need each of those servers to have a full copy of every file. Imagine I could say, "Make sure than any one block is automatically stored on at least 6 servers". Now I have 100 TB of redundant storage online accessible via the bittorrent protocol. Then I could have different individual clients set to only sync a certain subset of that storage.
If you have symmetric up/down, then there would be no speed advantage.
Well I suppose it still depends. Imagine you have 20 computers staying in sync, all through symmetric 10mbps connections, then you add another. Even if the additional computer only has a 10Mbps connection, meaning you may not get the download faster than simply downloading from one source, you could still see a benefit from distributing the load among the other 20 computers. So instead of saturating the upload pipe for one computer, you're a minor .5mbps upload on each.
The entropy-maximization isn't about complex, "long-term" planning for "future states" on a how-to-survive-to-next-year, or even how-to-survive-to-next-hour, time scale.
So then am I wrong if that makes me suspicious that it won't model behavior very well in general? A model that doesn't account for decisions that sacrifice possible "states" in the next 30 seconds for some benefit 3 minutes from now? I wouldn't deny that many kinds of behavior are very short-sighted, but the more we talk about it, the more deficient it seems.
It's a model for generating short-term actions (e.g. "move towards the stick and grab it; push the stick towards the trapped food)
Now if the crow moves towards the stick to "maximize states" and then grabs the sticks to "maximize states", then why aren't crows always moving towards sticks and grabbing them, even when there's no trapped food?
Well most modern models of intelligence/consciousness (at least that I've read about or heard about) imply that it's some kind of emergent property of complex heuristics. Now that's a vague explanation, but there seems to be a consensus that it's something like that.
I don't understand the "generic physics-motivated" model, but I'd imagine it would run into a lot of shortcomings. Crows maximize the number of future states available? It seems like that might be roughly true in some circumstances without being at all causal. Do the number of future states increase when an organism survives for longer? Then is it "maximizing states" or "maximizing survival"?
And how do you account for mistakes and misunderstandings? How do you account for instances of poor decision-making? Behavior is pretty complex.
To me, this at least seems less bonkers than (now mostly outdated) approaches that tend towards assuming something that looks like formal syllogistic symbolic logic generates "smart" behaviors.
I guess so, but I don't know if the "experts" in psychology or AI think that intelligence is generated through logical syllogisms. So I don't necessarily doubt that crows are using some kind of heuristics when they decide to use a stick, but I have some doubts about whether the heuristics are so simple that they can be modelled accurately without considering the biology and psychology of the crow itself.
Many cognitive models might approach this by assuming the crow has a big table of "knowledge" that it can logically manipulate to deduce an answer... This paper, however, proposes a much more general and simple model... the crow lives by the rule "I'll do whatever will maximize the number of different world states my world can be in 5 seconds from now." By this principle, the crow can reach a lot more states if it can move the stick... This provides a very general mechanism for cognition driving a wide variety of behaviors, that doesn't require the thinking critter to have a giant "knowledge bank" from which to calculate complicated chains of logic before acting.
There may be an interesting insight in there, but it doesn't seem to me to solve the problem. It seems to me that you haven't changed the mechanism, but rather the motivation for acting-- from "hunger" to "maximizing states". Actually, I'm not even sure you've changed the motivation, but rather reframed it.
It seems like you haven't removed the need for a "knowledge bank" or "chain of logic", unless you've described the mechanism for how "maximized future states" is converted into "crow behavior". Does the crow "know" which behavior will result in maximizing his states, or is it achieved in some other way?
Sociobiologists come up with plausible and reasonable sounding theories for many of these, but most of them remain just guesswork if there isn't hard data and hard mathematical modeling
I find this to be a good reason why we should bring back "natural philosophy" (and other philosophical branches) as fields which are not considered "science". Right now, there's such a push to apply science to philosophy or to make philosophy a subset of science, or just as bad-- to argue that philosophy is obsolete now that we have science.
In truth, there's a lot of room for people to be generating concepts and ideas independent of determining how to test those ideas, or even whether it makes sense to try to test them. Many of the things we currently call "science" don't lend themselves to the scientific process very well. They don't make for easy controlled experiments, and are inherently going to be guesswork without hard data. In fields like psychology and economics, even when we have "hard data" and "mathematical modeling", there's still too much interpretation to be thrown into the same group as physics, chemistry, and biology.
For example, it doesn't make sense to try and split the coding into a "creative coder" (who knows nothing about programming) and an "implementation coder" who turns the creative's ideas into actual code. The creative would toss out nonsensical ideas (like "instead of using vectors, why not use genetic algorithms?"), and then the implementer would have to explain why all those ideas are silly... or else they would just have to ignore the creative type and simply code something that makes sense.
But couldn't there be someone who says, "I want you to write code that does this..." and have someone else write the code? I'm not a coder, but I know I've been in situations where I worked out the logic and math of a problem, handed off some pseudo-code to a real programmer, and said, "Turn this into real code and optimize it." I'm not enough of a programmer to know whether the code that resulted was ideal, but it certainly worked as intended. I've also worked with a programmer and said, "I want a program that optimizes for this..." and he came up with the math to do that all on his own.
Now I think it's good to have knowledge across a lot of disciplines, but I don't see what the problem is with a little teamwork. It seems just as likely to me that you'll get errors from people making non-mathematical assumptions about fields they don't understand. Like you could be a medial researcher and brilliant statistician studying a new anti-depressant and misread the data because you don't understand psychology sufficiently to be measuring the right indicator. So why shouldn't we have people from different areas and fields working together?
This story [computerworld.com] indicates that "unusual events" happen a few times a year
"A few times a year" is pretty common in my book. And let's not forget that even if the outage is precipitated by a normal holiday, that doesn't preclude the possibility that people would be having emergencies during that time, and be prevented from calling for help.
Everything I've read implies that expanding them to handle rare emergency loads costs a lot and there just isn't a good case for spending that kind of money.
This is exactly what I find to be dishonest about the way you talk, right here: "there just isn't a good case". Obviously there's a good case. It could save lives. Not just "could", but "almost certainly would". If it's too expensive to justify that should be a painful unfortunate reality, and not something to be dismissed as though there's just no argument to be had.
Emergency crews, firefighters, and police, the bulk of the official response to disaster and such, for example, rely on radio not on cell phones.
Right, so you're claiming that telephones are unimportant during an emergency.
These things are rare. We don't have to speculate, we just look at the occurrence of actual large scale emergencies that overwhelm the local cell network infrastructure.
How rare? I ask because I'm pretty sure you're just making this up. And what about other unrelated things that happen during an emergency? Someone bombs Boston, and what about a robbery that happens at the same time? Any one scenario is rare, but when you add up all the various possible rare scanarios, are they really so unrealistic?
The world has had earthquakes, tsunami, landslides, riots, explosions and fires, and power outages and such. These routinely take out cell network infrastructure.
Those aren't the only emergencies that overwhelm cellphone networks, and those events don't always damage cellphone infrastructure so as to make the infrastructure useless regardless of traffic. If you really want to argue, provide some examples and statistics to prove your point. Otherwise, stop claiming weird counter-intuitive claims.
and yet, we might have to shut that network down when it's most needed.
Wait, so are you admitting here that cell phone infrastructure is needed during emergencies?
I note that wasn't what was said. If we're going to be "clear" about this, here's what was originally said:
And then you quote a bunch of stuff as though you hadn't really read any of it. First, I wasn't saying you specifically said that, but you are among many people making statements similar to that. You claim you never said, "nobody needs a telephone during an emergency." and yet you quote yourself saying, "We don't rely on the cell phone network in an emergency."
That's a very contrived situation.
It's one example of how a cell phone might help you in an emergency. That situation might be rare, but if you start aggregating all of the possible rare emergency situations where a cell phone might be helpful, I think you'll find that it's probably not such a rare thing. Plus, it's not much more contrived to say, "maybe you'd be injured by conscious and emergency services wouldn't know where to look for you," than to say, "well maybe emergency services would find you if you banged on something." They're trained to listen for noise, not because they'll necessarily be able to find anyone making noise, but because *they have nothing else to go on*.
Anyway, my whole point, over and over again, is if you really are ok with the situation, then fine. Let's agree that it's not worth paying for a robust cell phone network that can function during emergencies. Let's make that very clear with everyone in the society, that you can't depend on cell phones in an emergency. But don't be evasive in our wording and pretend that having our telecommunications network fail during emergencies won't ever cost some lives. Let's just admit that we're saying, "saving those lives is too expensive."
These disasters include a considerable subset which damages or destroys the cell phone network.
First, that seems like a big assumption with no evidence behind it. Talk about a contrived situation. Yes, I suppose a nuclear bomb would knock out cell phones, but there are many kinds of emergency situations that won't knock out the cell phone network. And again, you're saying "There's no point in mitigating some risks because there will still be other risks."
Yet another risk which I didn't address is what happens when someone sets off bombs via cell phone triggers. Now, you might have to make a hard choice between keeping the cell phone network (and related emergency services) up and losing more lives due to bombs which haven't been triggered yet.
That's a totally different issue. Regardless of whether the cell phone network can handle capacity during an emergency, they could still shut down networks if they suspect it's going to be triggered by a cell phone. It's not really what we're talking about here.
I really don't see the point of arguing over this.
Says the guy who continues to argue over this despite not having good arguments.
Unfortunately some of the people replying to you are saying, essentially, "There are tech people on the market, but they're either under-qualified or they expect too much money." I say 'unfortunately' because this sentiment misses the point.
By their own argument, the problem isn't that there are no candidates, but that the candidates are expecting 'too much money'. While they might think their expectations are unrealistic, if you really can't find someone suitable for cheaper, then via supply/demand, that's the going rate. So essentially the salaries they're requesting are probably appropriate given that their skills are in high demand and there's a limited supply, but employers want so change the supply/demand balance by flooding the market with cheap foreign labor, thereby driving down programmers' wages.
Now we can argue about whether or not that's a fair thing to do, but let's not pretend it's about a lack of skilled workers. It's about businesses wanting to cut labor costs.
When I used Siri for the first time and realized it was sending my questions to a datacenter somewhere, I had an immediate reaction of "that's a bit creepy and disconcerting." But once the data is sent out to the datacenter for processing, you've already opened the door for the data to be misused. Once you assume that the data will be stored for some amount of time, you increase the chances for the data to be misused. But if you extend the time that the data is stored for a for months or a year, I don't feel like you're greatly increasing your exposure.
What holding on the data actually does is it gives Apple some time to process and analyze the data, improving the speech recognition and heuristic models. I'd expect them to want to keep it for a couple years, especially since Siri is new and they're probably still developing their methods for analyzing the data. In this sort of situation, having more data means being able to create a more accurate analysis.
As long as Microsoft has the strongest commitment to backwards compatibility, they'll retain their market position.
Yes, they'll retain their position in that market, but but maybe the question is "how small will that market shrink?"
Not really.
Gold is ultimately as valuable as it is because it has a history of being "Ooooo! Shiny!" Because of we all agree that gold is awesome and shiny, be agree on a set price through a process not too different from setting the price of fiat currency. If everyone suddenly agreed that gold was no longer pretty, the value would implode just like fiat currency.
Which only raises the question: What's the value of gold backed by?
I get the sense that you think you're arguing with me, but I don't see how you are.
if we had a pill that would completely wipe out the flu in your body with no adverse side effects, I think we would use that instead of a decongestant. Sure, we treat the symptoms as a stopgap or when we can't fix the root cause but ultimately, we fix the root cause whenever we're able.
That's essentially the reason that people who favor affirmative action hold that position. We don't have a pill that can completely wipe out cultural bias, so we treat the symptoms as a stopgap, hopefully allowing these biases to "heal naturally".
Sucks to be you then. I still don't get why these contrived scenarios are supposed to justify spending a lot of money beefing up cell phone coverage. It is rare for an activity to be completely absent of benefit for anyone.
My whole point, as stated several times, is that we should be honest about the decision we're making. If you want to say, "It's not worth the money to have our telephone infrastructure robust enough to continue to operate during an emergency," then I'm not convinced that you're wrong.
However, let's be clear about it. Let's not say, "Well, emergencies never really happen and nobody needs a telephone during an emergency." That's dishonest. To give an alternate example, if you said, "It's not worth lowering the highway speed limit to 25 miles per hour. Sure, having it as high as 55 mph will mean more people die in car accidents each year, but preventing those deaths is not worth the economic and social impact of slowing car travel so much," then I wouldn't really have an argument. But don't try to argue, "Well going 25 mph is just as safe and car crashes never really happen anyway."
No. I can't see that analogy. I think it's more like saying that putting a lot of money into beefing up a cell phone network still has the major problem that there are a variety of disasters that could take down the cell network anyway.
Right, hence the analogy. "There's no point in mitigating some risks because there will still be other risks." It's a bad argument. Risks are additive, and so having multiple different kinds of risks makes it even more important to mitigate risk where possible.
Isn't that how we all "do it"? Aggressively pursuing women who meet our "requirements"?
what I see reported as the biggest turn-off to most women is the perception that tech work, computer science in particular, is "geeky"
Sounds like the problem is that women are too smart to work in tech.
Did they address the question of whether this brain pattern was the result of nature or nurture?
That tends to be a difficult question, since you can't have controlled experiments.
You're saying the problem is with people that have identified a potential root cause, rather than just trying to treat the symptoms? I sure hope you're not a doctor.
We often treat symptoms rather than the root cause. If you're seriously injured, they might give you a pain reliever and something to reduce swelling. If have the flu, they might recommend a fever reducer and decongestant/expectorant. If you have lung cancer, they don't try to go back in time to prevent you from smoking. The focus is generally on reducing the symptom of "death".