If you read the link at the top of the linked post, you'll see that Google says they will support pseudonyms. Not right now, but eventually.
People who NEED pseudonyms now should not use Google+. When it meets their needs, then they can hop on, if they like. I think Google is doing the right thing in not trying to support every use case right out of the starting gate.
I can easily see this manifesto being picked up by the militias in the United States and secretly admired as a great work. Scary.
I don't see why you find that scary. Would you also find it scary if a nutcase killed a bunch of people after publishing a manifesto that is a slightly more extreme version of your political positions (whatever they are)?
The manifesto and the guy's ideas ultimately had little to nothing to do with his actions. They were justification and window dressing, but he could have used a completely different set of ideas just as well. And there may well be plenty of people in the US who would read his manifesto and agree with it, but that doesn't mean they're going to do anything similar, or that they don't deplore his violence just as much as you do -- perhaps more.
In my experience, most people who perform the role you describe aren't software engineers, they're technically-minded business analysts, good at extracting requirements and perhaps painting the broadest strokes of an architecture, but need someone who really understands code to refine their architectures and turn them into good designs, and then good code.
Have you ever seen the proof of a^2 + b^2 = c^2? No? Of course not.
Not arguing with the rest of your post, but if you've never seen the Pythagorean Theorem proved, your mathematical education missed a really basic and important opportunity. Every geometry course should include at least one version of that proof, and it should be outlined in first-year Algebra.
You seem to forget that the basic tenet on "technical debt" is "debt". There's not debt if there's no expectancy of having to repay it.
I didn't forget it, I explicitly stated it.
However, you're certainly right that this is an area where the analogy with financial debt breaks down. Another is the fact that quick-n-dirty code in the hands of the original author often appears to have no "interest" cost -- that person can use, modify and enhance the code with great speed and effectiveness.
I think it's worth looking under the covers of the analogy to see why it breaks down. The reason is that technical debt is really just an artifact of obscurity. Well-designed and well-written code is easy to understand because it's transparent and complete, and accompanied by documentation that provides the knowledge necessary to work with it, and tests that enable modification-introduced bugs to be quickly identified and corrected. Bad code has all sorts of edge cases that simply aren't written (or are but don't work), the code is convoluted and hard to understand and the documentation and tests are missing, deficient or -- in the worst cases -- actively misleading.
To a person that knows the code, these defects are basically irrelevant, so the debt is invisible and "interest free". Once the codebase grows to a point that no one can know it all, or gets passed onto others, then the debt raises its head.
This is why debt isn't a perfect analogy for the original developer or (small) development team. But it is a great analogy in the common case, which is a large codebase passed down through many "generations" of developers. Well, the common case for most product and company-internal code, anyway. Not for most research code, as you pointed out.
If I'm getting this right, scientists view software as nothing more than a specialized calculator.
I can certainly confirm that as an engineer, that's certainly how I view it. Almost literally in most cases.
But I have never deluded myself that our really complicated calculator programs would be appropriate for some sort of deliverable product for general use. In fact I repeatedly try to make that point and people still don't get it. And usually "Software engineers" expect a bunch of their absurd rituals to be followed anyway, even if it's never going to go anywhere or be used by anyone but me. So I would contend that the professional programmers and particularly the software process types are the ones who don't grasp the concept.
Brett
Brett
Here's a tool that may be helpful to you in explaining the issue to various people: "Technical Debt". Your quick-n-dirty code that does what you need it to do carries a great deal of technical debt, but the nature of its limited use means the interest payments are small, so there's no value in paying down the debt. Start trying to turn it into a product to be used by many people, however, and you'll quickly find that the interest payments are unbearable, and that it costs a great deal of effort to pay off the technical debt, to turn the code into something that is maintainable.
You can thank the software engineers for that elegant and powerful notion:-)
There's a nice concept devised by Ward Cunningham which captures this issue nicely: "Technical debt".
Failing to put in the effort that makes code maintainable during its construction incurs a notional "debt" which the software carries with it. Future developers working on the code "pay interest" on this debt in the form of time wasted on understanding and modifying the crappy, undocumented code, or on fixing bugs that wouldn't have been present if the code were better. Sometimes, those future developers may decide to spend time refactoring, building tests or documenting, and those cleanups pay down the "principal" on the "debt". After their cleanup work is done, future work has smaller interest payments (less effort for the same results).
Startups often deliberately decide to incur great amounts of technical debt on the theory that if the revenue starts flowing in they'll have the money to fund paying it down, but if they don't start getting some money the whole company will evaporate.
For scientific research, it's pretty clear that it also makes sense to incur lots of technical debt in most cases, because there's little expectation that the code will be used at all once the research is complete. Even when that's not the case, I think few scientists really know how to create maintainable software, because it normally is the case. I don't see a lot of scientists spending time reading about code craftsmanship, or test-driven design, or patterns and anti-patterns, or... lots of things that at least a sizable minority of full-time software engineers care a lot about.
I guess the bottom line, to me, is that this article is blindingly obvious, and exactly what I'd expect to see, based on rational analyses of the degree of technical debt it makes sense for different organizations to incur.
Remember that Google has no customer service, even for paying customers.
Actually, Google does have customer service for paying customers. This is something that has changed in the last year or two, though, so it's not surprising people don't know about it.
As of now you can't use your apps domain account; it's not supported.
By the time it is, I suspect Google will have addressed the issues and found a way to enforce the Google+ real name policy without locking people out of the rest of Google services. Eventually I expect that Google will allow pseudoymous Google+ use as well, but I don't think that's your concern.
MOD THIS UP! Finally someone gets it. From all the Google articles I've seen you're the only one who seems to grasp this!
FWIW, that's now how Google sees it. Google sees the user and the advertiser both as customers, and most of the company tends to focus mostly on the user.
But without making the battery state visible to the OS, the OS would not be able to adjust its operation based on the battery state. And, yes, OS X does that, and it's a good thing. Not only that, whatever useful interactions the OS and firmware have now, it's always possible that future software updates could make both, and their interaction, even more effective. Leaving that possibility open is good engineering.
The problem here is poor implementation of the security component of the system, not bad design.
On the other hand, all of your concerns about Google are concerns that I share. What prevents them from selling their data to insurance companies, Lexis Nexus, ChoicePoint, or any other data aggragator (sp) with the money to pay for it?
Nothing really "prevents" them... but self-interest and good citizenship both argue against it. And, regardless of what all the slashbots spout about how no corporation can do anything other than focus on the bottom line, Google does actually care about being a good citizen.
But even if you don't buy that, self-interest and arrogance pretty much ensure it. Google is convinced that they can more accurately and effectively monetize your information than anyone else can. They can do a better job of deciding what ads you will be interested in seeing than any of the companies who want to advertise to you, and they can therefore do a better job of turning you into a revenue stream for someone (and, since they're showing you stuff you're really interested in, the theory is that you not only won't mind, you'll appreciate it). So, they keep the data to themselves for that reason and because violating their users' privacy would lead to a huge backlash outside and inside the company and -- honestly, this really is a key issue in privacy-related discussions within Google -- because it would be wrong.
The "safety net problem" is far bigger than that, indeed. Mostly, it's due to parents who would love to pack their kids in cotton boxes
The safety net problem is far bigger than just parents and how they treat their kids. A huge number of adults believe they don't have to take responsibility for their own futures because someone else will take care of them. This shows up in all sorts of ways, from people building houses in flood plains or on the sides of unstable mountains, to people expecting that the police can keep them safe from bad people, to people not bothering to understand the terms of the mortgage contracts they sign, to... I could go on all day.
Safety nets encourage ignorance of risks and a failure to develop necessary risk-avoidance skills and risk-management strategies in all sorts of situations, just as much for adults as for children.
One is the unconstitutional search by an agent of the federal government without warrant or probable cause. No one can tell me that attempting to take a flight in an airplane is probable cause to a government search for explosives or weapons.
Unfortunately, it's not an unconstitutional search. If government agents have your permission to search you and your stuff then they don't need a warrant or probable cause, and the fact is that when you fly you're voluntarily submitting to that search. Of course, if you don't submit you can't fly, but the courts are of the opinion that while you have a right to travel you don't have a right to travel via a particular mode of transportation. Unless we can get the courts to decide that flying is a right which cannot be denied by the government they can continue to consider your decision to fly as voluntary acceptance of the search.
Back to the point, the real problem with the scanners isn't the pictures or the "radiation", it's the blatent invasion of privacy and expenditure of tax dollars on security theatre.
I think there are multiple problems, and radiation exposure may well be one. While the scanners expose individuals to a relatively low overall radiation dose, the delivery concentrates this dose in the top few millimeters of the skin. We really don't know what effect this may have, because the per-tissue-volume dose is significantly higher than, for example, medical diagnostic x-rays. It's also not clear that the scanners deliver that dose uniformly, there may be even hotter spots. Since the TSA won't allow independent experts to evaluate the machines, we don't know. For that matter, we have only the TSA's word regarding the field intensities, again because they permit no independent researchers to evaluate the machines.
It is possible that the radiation issue is negligible. It's also possible that it's not.
Added to that, the machines are unnecessary, ineffective, invasive and expensive. We need to get Congress to step in and simply shut that program down. For that matter, I'd really prefer we eliminated the TSA from airports altogether and returned to the pre-9/11 model, which worked just fine.
we'll have sufficient bandwidth that video shot from a mobile device can be uploaded straight to the web, with only a brief "buffering" stop on the actual filming device.
Yep. The effort is needed to teach the mother how to teach the baby how to do it. And lots of mothers and babies find it all very challenging.
Oddly, in my experience puppies, kittens, lambs and calves don't have a problem with knowing how to feed immediately they're born, nor their mohers in helping them.
Very true, but human newborns are far more helpless in virtually every way, so that shouldn't be so surprising. And, frankly, I think all babies and new mothers can figure it out on their own. The main advantage of the instruction is in reducing the time, effort and frustration. New mothers tend to be (understandably) very uncertain and worried about every little problem, so they can find their baby's difficulty with nursing to be disheartening and even quite frightening.
From a user's perspective it offers nothing over Linux. From an OS developer's perspective, it offers a new playground which does things differently and enables new approaches to be experimented with... which may (or may not) mean that years from now it offers something from a user's perspective.
Slashdot Mirror
who is google to tell me what my name should be? I'll put whatever I want in there.. their policy is asinine, quit defending it.
I think their policy makes sense, so I absolutely will defend it.
I'll also point out that no one is requiring you to use Google+.
people NEED the freedom to pick aliases.
If you read the link at the top of the linked post, you'll see that Google says they will support pseudonyms. Not right now, but eventually.
People who NEED pseudonyms now should not use Google+. When it meets their needs, then they can hop on, if they like. I think Google is doing the right thing in not trying to support every use case right out of the starting gate.
I can easily see this manifesto being picked up by the militias in the United States and secretly admired as a great work. Scary.
I don't see why you find that scary. Would you also find it scary if a nutcase killed a bunch of people after publishing a manifesto that is a slightly more extreme version of your political positions (whatever they are)?
The manifesto and the guy's ideas ultimately had little to nothing to do with his actions. They were justification and window dressing, but he could have used a completely different set of ideas just as well. And there may well be plenty of people in the US who would read his manifesto and agree with it, but that doesn't mean they're going to do anything similar, or that they don't deplore his violence just as much as you do -- perhaps more.
I don't think it's possible to be a really good software engineer without also being a really good programmer. http://users.rcn.com/jcoplien/Patterns/Process/section16.html
In my experience, most people who perform the role you describe aren't software engineers, they're technically-minded business analysts, good at extracting requirements and perhaps painting the broadest strokes of an architecture, but need someone who really understands code to refine their architectures and turn them into good designs, and then good code.
Have you ever seen the proof of a^2 + b^2 = c^2? No? Of course not.
Not arguing with the rest of your post, but if you've never seen the Pythagorean Theorem proved, your mathematical education missed a really basic and important opportunity. Every geometry course should include at least one version of that proof, and it should be outlined in first-year Algebra.
For your own edification, I suggest reading and understanding a few proofs of the theorem. A very complete collection can be found here: http://www.cut-the-knot.org/pythagoras/index.shtml
You seem to forget that the basic tenet on "technical debt" is "debt". There's not debt if there's no expectancy of having to repay it.
I didn't forget it, I explicitly stated it.
However, you're certainly right that this is an area where the analogy with financial debt breaks down. Another is the fact that quick-n-dirty code in the hands of the original author often appears to have no "interest" cost -- that person can use, modify and enhance the code with great speed and effectiveness.
I think it's worth looking under the covers of the analogy to see why it breaks down. The reason is that technical debt is really just an artifact of obscurity. Well-designed and well-written code is easy to understand because it's transparent and complete, and accompanied by documentation that provides the knowledge necessary to work with it, and tests that enable modification-introduced bugs to be quickly identified and corrected. Bad code has all sorts of edge cases that simply aren't written (or are but don't work), the code is convoluted and hard to understand and the documentation and tests are missing, deficient or -- in the worst cases -- actively misleading.
To a person that knows the code, these defects are basically irrelevant, so the debt is invisible and "interest free". Once the codebase grows to a point that no one can know it all, or gets passed onto others, then the debt raises its head.
This is why debt isn't a perfect analogy for the original developer or (small) development team. But it is a great analogy in the common case, which is a large codebase passed down through many "generations" of developers. Well, the common case for most product and company-internal code, anyway. Not for most research code, as you pointed out.
I can certainly confirm that as an engineer, that's certainly how I view it. Almost literally in most cases.
But I have never deluded myself that our really complicated calculator programs would be appropriate for some sort of deliverable product for general use. In fact I repeatedly try to make that point and people still don't get it. And usually "Software engineers" expect a bunch of their absurd rituals to be followed anyway, even if it's never going to go anywhere or be used by anyone but me. So I would contend that the professional programmers and particularly the software process types are the ones who don't grasp the concept.
Brett
Brett
Here's a tool that may be helpful to you in explaining the issue to various people: "Technical Debt". Your quick-n-dirty code that does what you need it to do carries a great deal of technical debt, but the nature of its limited use means the interest payments are small, so there's no value in paying down the debt. Start trying to turn it into a product to be used by many people, however, and you'll quickly find that the interest payments are unbearable, and that it costs a great deal of effort to pay off the technical debt, to turn the code into something that is maintainable.
You can thank the software engineers for that elegant and powerful notion :-)
There's a nice concept devised by Ward Cunningham which captures this issue nicely: "Technical debt".
Failing to put in the effort that makes code maintainable during its construction incurs a notional "debt" which the software carries with it. Future developers working on the code "pay interest" on this debt in the form of time wasted on understanding and modifying the crappy, undocumented code, or on fixing bugs that wouldn't have been present if the code were better. Sometimes, those future developers may decide to spend time refactoring, building tests or documenting, and those cleanups pay down the "principal" on the "debt". After their cleanup work is done, future work has smaller interest payments (less effort for the same results).
Startups often deliberately decide to incur great amounts of technical debt on the theory that if the revenue starts flowing in they'll have the money to fund paying it down, but if they don't start getting some money the whole company will evaporate.
For scientific research, it's pretty clear that it also makes sense to incur lots of technical debt in most cases, because there's little expectation that the code will be used at all once the research is complete. Even when that's not the case, I think few scientists really know how to create maintainable software, because it normally is the case. I don't see a lot of scientists spending time reading about code craftsmanship, or test-driven design, or patterns and anti-patterns, or... lots of things that at least a sizable minority of full-time software engineers care a lot about.
I guess the bottom line, to me, is that this article is blindingly obvious, and exactly what I'd expect to see, based on rational analyses of the degree of technical debt it makes sense for different organizations to incur.
Remember that Google has no customer service, even for paying customers.
Actually, Google does have customer service for paying customers. This is something that has changed in the last year or two, though, so it's not surprising people don't know about it.
As of now you can't use your apps domain account; it's not supported.
By the time it is, I suspect Google will have addressed the issues and found a way to enforce the Google+ real name policy without locking people out of the rest of Google services. Eventually I expect that Google will allow pseudoymous Google+ use as well, but I don't think that's your concern.
MOD THIS UP! Finally someone gets it. From all the Google articles I've seen you're the only one who seems to grasp this!
FWIW, that's now how Google sees it. Google sees the user and the advertiser both as customers, and most of the company tends to focus mostly on the user.
Wouldn't it HAVE to be growing?
This is about as meaningful as saying your toddler is growing. What else is it going to do? The only way IS up.
It's not that it's growing, it's that it's growing extremely quickly. It's like saying your toddler is growing an inch per day.
But without making the battery state visible to the OS, the OS would not be able to adjust its operation based on the battery state. And, yes, OS X does that, and it's a good thing. Not only that, whatever useful interactions the OS and firmware have now, it's always possible that future software updates could make both, and their interaction, even more effective. Leaving that possibility open is good engineering.
The problem here is poor implementation of the security component of the system, not bad design.
On the other hand, all of your concerns about Google are concerns that I share. What prevents them from selling their data to insurance companies, Lexis Nexus, ChoicePoint, or any other data aggragator (sp) with the money to pay for it?
Nothing really "prevents" them... but self-interest and good citizenship both argue against it. And, regardless of what all the slashbots spout about how no corporation can do anything other than focus on the bottom line, Google does actually care about being a good citizen.
But even if you don't buy that, self-interest and arrogance pretty much ensure it. Google is convinced that they can more accurately and effectively monetize your information than anyone else can. They can do a better job of deciding what ads you will be interested in seeing than any of the companies who want to advertise to you, and they can therefore do a better job of turning you into a revenue stream for someone (and, since they're showing you stuff you're really interested in, the theory is that you not only won't mind, you'll appreciate it). So, they keep the data to themselves for that reason and because violating their users' privacy would lead to a huge backlash outside and inside the company and -- honestly, this really is a key issue in privacy-related discussions within Google -- because it would be wrong.
If you go over here,, you'll find out the biggest reason it's getting popular.
Hint: It's not facebook.
Pay special attention to the onmouseover tooltip. I think it nails a big reason lots of people are moving.
The "safety net problem" is far bigger than that, indeed. Mostly, it's due to parents who would love to pack their kids in cotton boxes
The safety net problem is far bigger than just parents and how they treat their kids. A huge number of adults believe they don't have to take responsibility for their own futures because someone else will take care of them. This shows up in all sorts of ways, from people building houses in flood plains or on the sides of unstable mountains, to people expecting that the police can keep them safe from bad people, to people not bothering to understand the terms of the mortgage contracts they sign, to... I could go on all day.
Safety nets encourage ignorance of risks and a failure to develop necessary risk-avoidance skills and risk-management strategies in all sorts of situations, just as much for adults as for children.
Bluetooth supports cryptography. NFC does not.
This is false. NFC's ISO 14443 mode is a smart card protocol which supported cryptography before Bluetooth existed.
The courts disagree that the one implies the other.
One is the unconstitutional search by an agent of the federal government without warrant or probable cause. No one can tell me that attempting to take a flight in an airplane is probable cause to a government search for explosives or weapons.
Unfortunately, it's not an unconstitutional search. If government agents have your permission to search you and your stuff then they don't need a warrant or probable cause, and the fact is that when you fly you're voluntarily submitting to that search. Of course, if you don't submit you can't fly, but the courts are of the opinion that while you have a right to travel you don't have a right to travel via a particular mode of transportation. Unless we can get the courts to decide that flying is a right which cannot be denied by the government they can continue to consider your decision to fly as voluntary acceptance of the search.
Back to the point, the real problem with the scanners isn't the pictures or the "radiation", it's the blatent invasion of privacy and expenditure of tax dollars on security theatre.
I think there are multiple problems, and radiation exposure may well be one. While the scanners expose individuals to a relatively low overall radiation dose, the delivery concentrates this dose in the top few millimeters of the skin. We really don't know what effect this may have, because the per-tissue-volume dose is significantly higher than, for example, medical diagnostic x-rays. It's also not clear that the scanners deliver that dose uniformly, there may be even hotter spots. Since the TSA won't allow independent experts to evaluate the machines, we don't know. For that matter, we have only the TSA's word regarding the field intensities, again because they permit no independent researchers to evaluate the machines.
It is possible that the radiation issue is negligible. It's also possible that it's not.
Added to that, the machines are unnecessary, ineffective, invasive and expensive. We need to get Congress to step in and simply shut that program down. For that matter, I'd really prefer we eliminated the TSA from airports altogether and returned to the pre-9/11 model, which worked just fine.
we'll have sufficient bandwidth that video shot from a mobile device can be uploaded straight to the web, with only a brief "buffering" stop on the actual filming device.
qik.com
Yep. The effort is needed to teach the mother how to teach the baby how to do it. And lots of mothers and babies find it all very challenging.
Oddly, in my experience puppies, kittens, lambs and calves don't have a problem with knowing how to feed immediately they're born, nor their mohers in helping them.
Very true, but human newborns are far more helpless in virtually every way, so that shouldn't be so surprising. And, frankly, I think all babies and new mothers can figure it out on their own. The main advantage of the instruction is in reducing the time, effort and frustration. New mothers tend to be (understandably) very uncertain and worried about every little problem, so they can find their baby's difficulty with nursing to be disheartening and even quite frightening.
From a user's perspective it offers nothing over Linux. From an OS developer's perspective, it offers a new playground which does things differently and enables new approaches to be experimented with... which may (or may not) mean that years from now it offers something from a user's perspective.
Yep. The effort is needed to teach the mother how to teach the baby how to do it. And lots of mothers and babies find it all very challenging.
Also, Google marketing has managed to make Google the new word for search
Google "marketing" did no such thing. Google users did that.