Sorry, to correct my statement about the employer reporting mandates: They technically exist, but they were "delayed"/waived-for-2014 before the other provisions that have been recently "delayed". The Feds had roughly four years to set up a reporting system and failed, which I think goes a long way to illustrating how not-"light in comparison" Obamacare is, relative to a simple voter ID bill.
I have read quite a bit of the PPACA, although I admit that I have much better things to do with my time than read all ~2000 pages of it.
I did not mention all the government actions that are necessary to implement Obamacare -- those are irrelevant to my earlier point, which was that the text of the bill is only a small part of the rules and regulations that make up the law. If you think that the executive-branch costs to implement Obamacare are "light in comparison" to the NC voter ID bill, you are absolutely nutters.
Setting aside all the rest of the bill, the government-run health insurance exchanges are (arguably, but I believe) more costly and more invasive than that voter ID bill -- and there needs to be a different exchange for each state. Enforcement of the individual and employer mandates are also daunting tasks. For example, there is no legal mandate for employers to report which employees were offered a qualifying health care plan (and probably no authorization for HHS or any other government agency to require pro-active reporting), so deciding whether a person gets an insurance subsidy from the federal government requires some government drone to call the employer(s) in question and ask -- and some employee needs to get such a subsidy before the employer has to pay the employer mandate's penalty. (Did you ever wonder why the Obama administration wants to delay that particular provision even though the black letter of the law says it will take effect January 2014, or why it also wants to use the honor system to figure out who is eligible for those subsidies?)
If the NIMBYs won, why does the law still require the NRC to do what this court has ordered it to do?
If you said "because Harry Reid has a problem with the rule of law", you win one eCookie. But you probably said something stupid like "the court is endlessly appealing its earlier rulings", so no points for you.
Are you a moron, or just ridiculously gullible? The text of the PPACA may only be a bit longer than a state's biennial budget, but it requires dozens or hundreds of executive offices to add tens of thousands more pages of regulations and other rule-making on top of the legislative part of the law. It's stupid political spin to ignore those when they control an awful lot of the law's substance -- don't fall for that type of dishonest stupidity, or whatever. On top of that, the bill was written essentially in "patch" form; it modified a lot of other laws scattered across the United States Code, and you need to consult the rest of those titles to understand what it really means. (This is part of why it's so hard to resist making "we have to pass the bill to find out what's in it" japes.)
As a side note, the Internal Revenue Code is also impossible to apply -- either in the abstract, or in a way that the IRS will accept -- without reference to more decisions and regulations that the IRS and its courts have promulgated over the decades. It contains too many ambiguities and external references, and some of the agency interpretations run counter to what a layperson might understand as the natural or most obvious meaning of the text.
Many contractors have quite a bit of experience in managing project failures -- either succeeding just enough to encourage the customer to throw good money after bad, or highlighting the less disastrous results in order to explain why the next contract will succeed where the last one failed.
The same is true for most non-government contractors who work on large, one-of-a-kind contracts. The fundamental reason those projects are hard to predict, hard to manage, and hard to fix is that they tend to be very complicated and significantly different than what people have done before. Those differences from previous experience make it hard to figure out in advance where a given project will behave differently than previous jobs, and lend themselves to just-so stories when it comes to explaining the failures (no matter whether that explanation comes with positive or negative spin).
That approach works well if you're selling many, many copies of your software, or if the customer representative is intimately familiar with the customer's actual needs. For most more specialized development efforts, having a customer representative ends up adding a middleman, confusion and extra work.
What is the difference to actual development between "we have a launchable product after each sprint" versus "we launch our product after each sprint"? There are obvious differences to the users, but what makes the former superior to the latter when it comes to meeting the overall project goals?
Also, there are a lot of non-agile alternatives, many of which do (or can) incorporate periodic release-candidate checkpoints. It is simply not accurate to talk about "the" non-agile alternative.
While no process will reliably produce good software with a dysfunctional team, Agile seems to be much more sensitive to dysfunction than many other processes. If you have a team full of disciplined, skillful individuals led with integrity by focused managers, many well-documented software processes will let you deliver good software on schedule. In the real world, teams often fall short of that ideal, so it is important for a development method to be somewhat robust to imperfect use, but Agile seems to encourage frequent distractions and excessive back-and-forth.
Funnily enough, most (academic) software engineering researchers understand that "waterfall" was originally intended as an exaggerated -- strawman -- description of a methodology that nobody uses in practice. Most practitioners also understand that any non-trivial project involves some backtracking, and most involve some iteration on parts of the development lifecycle, and thus don't try to use a strict waterfall method. Most Agilistas didn't get either memo.
Your outline of running a software project applies equally well to a spiral method or a CMMI-compliant method or a lot of ad hoc methods without using any defined process. The practical problems with Agile are in the details that you glossed over that distinguish Agile from those alternative methods. Those other methods are not always better than Agile, but Agile is not always better -- and is frequently worse -- than them.
One of the hardest things for process designers to do is to fit their processes to the people who will use them.
Most hard-core proponents of Agile don't understand this. This shows up in the small number of places that do stand-up meetings right, that do automated *and* thorough testing right, that elicit useful input and direction from the customer, and so forth. Once you throw all the Agile processes together, few places can do most of it right, and that's one of the biggest reasons that Agile ends up being a poor fit so often.
When projects inevitably fail in those circumstances, it is just annoying human behavior that makes the Agilistas claim the failure is due to not doing Agile hard enough rather than doing Agile in the first place, and that's one of the biggest reasons that Agilistas end up being obnoxious blowhards so often.
Agile dictates that you have practically continuous customer input to the development process. How do you propose to get that -- and to communicate your expectations about those interactions with the customer -- without telling them about the methodology?
Journals and conferences don't want to publish negative results, so you very seldom hear about all the people who try a process and find that it sucks for them.
Process success stories in the software field have always been driven more by special circumstances than science. Nobody has yet figured out how to (or at least bothered to) control for variations in sample-group productivity well enough to generate reproducible results for most process changes, and all the practitioners want to optimize their processes for different things. For example, CMMI and its ancestors are good if you have a load of time, good requirements control, and a few good leaders mixed with a bunch of more ordinary workers; Agile is good if your customers value whims over checking all the boxes and having really robust software; etc.
Finally, software changes can have chaotic effects, which makes it hard to apply a lot of the control, prediction and robustness methods used in other engineering fields. This makes me think that there will always be a large element of individual skill and domain expertise in building and delivering successful software, and that processes will always need to be carefully chosen based on the team and the project.
If you're not doing Xtreme Agile, you're not doing Agile right.
Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.
You don't even have to get that far, you just have to minimally comprehend the bit that the blurb quotes from the article: "Emissions from drilling, including fracking, and leaks from transmission pipes totaled 225 million metric tons of carbon-dioxide equivalents during 2011, second only to power plants".
Were Aaron Greene and Morgan Gliedman arrested recently for legitimate dissent? Or were they arrested for illegally possessing destructive devices (and apparently planning to use them against others)? Also, don't you find it ironic that OWS is so heavily staffed by children of privilege like those two?
So your argument is that "cost of physically performing" really means the same thing as "cost of performing", and that the FSF included the word "physically" for no reason? Somehow I'm not terribly convinced.
He was already in violation; he did not include either the source code or a written offer to provide source code with his binary version. If the binary version was accompanied by the source code, that would have ended his obligations; if it was accompanied by a written offer to provide source code, that would allow anyone to ask for the source code.
There are at least three problems with your interpretation. First, the binary form of the software appears to not include any offer to provide source code, so the $3.99 cost for a binary copy is not easily interpreted as the cost to provide a copy of the source code. Second, the language of the GPL specifically limits the cost to the "cost of physically performing source distribution"; the inclusion of the qualifier "physically" arguably excludes imputed labor costs. Third, to the extent that the language is ambiguous, US courts are supposed to interpret ambiguous clauses in standard form contracts against the party offering the contract, and there is room to view the distributor either as the party who accepted the GPL or the party who offered it (to the end user).
I sent a support request to the distributor asking where the source code is. Depending on the response to that, I might complain to Google and/or the DosBox developers. I would rather have the distributor mend his ways with as little third-party pressure as possible; I think that usually leads to a better FOSS environment in the long term.
I paid $3.99 for a copy, but that still does not give me any legal rights under the GPL; the GPL is between a distributor (the DOSBox Turbo guy) and the authors (contributors to DosBox) of a piece of software. The issue is that the distributor has not satisfied the terms of the license that allows him to create and distribute his derived work -- those do not allow him to sell binary copies and then only give source to people who paid for the binary.
Slashdot Mirror
... although I have to admit that New Yorkers pretty much keep asking for that level of government meddling in their lives.
Sorry, to correct my statement about the employer reporting mandates: They technically exist, but they were "delayed"/waived-for-2014 before the other provisions that have been recently "delayed". The Feds had roughly four years to set up a reporting system and failed, which I think goes a long way to illustrating how not-"light in comparison" Obamacare is, relative to a simple voter ID bill.
I have read quite a bit of the PPACA, although I admit that I have much better things to do with my time than read all ~2000 pages of it.
I did not mention all the government actions that are necessary to implement Obamacare -- those are irrelevant to my earlier point, which was that the text of the bill is only a small part of the rules and regulations that make up the law. If you think that the executive-branch costs to implement Obamacare are "light in comparison" to the NC voter ID bill, you are absolutely nutters.
Setting aside all the rest of the bill, the government-run health insurance exchanges are (arguably, but I believe) more costly and more invasive than that voter ID bill -- and there needs to be a different exchange for each state. Enforcement of the individual and employer mandates are also daunting tasks. For example, there is no legal mandate for employers to report which employees were offered a qualifying health care plan (and probably no authorization for HHS or any other government agency to require pro-active reporting), so deciding whether a person gets an insurance subsidy from the federal government requires some government drone to call the employer(s) in question and ask -- and some employee needs to get such a subsidy before the employer has to pay the employer mandate's penalty. (Did you ever wonder why the Obama administration wants to delay that particular provision even though the black letter of the law says it will take effect January 2014, or why it also wants to use the honor system to figure out who is eligible for those subsidies?)
If the NIMBYs won, why does the law still require the NRC to do what this court has ordered it to do?
If you said "because Harry Reid has a problem with the rule of law", you win one eCookie. But you probably said something stupid like "the court is endlessly appealing its earlier rulings", so no points for you.
Are you a moron, or just ridiculously gullible? The text of the PPACA may only be a bit longer than a state's biennial budget, but it requires dozens or hundreds of executive offices to add tens of thousands more pages of regulations and other rule-making on top of the legislative part of the law. It's stupid political spin to ignore those when they control an awful lot of the law's substance -- don't fall for that type of dishonest stupidity, or whatever. On top of that, the bill was written essentially in "patch" form; it modified a lot of other laws scattered across the United States Code, and you need to consult the rest of those titles to understand what it really means. (This is part of why it's so hard to resist making "we have to pass the bill to find out what's in it" japes.)
As a side note, the Internal Revenue Code is also impossible to apply -- either in the abstract, or in a way that the IRS will accept -- without reference to more decisions and regulations that the IRS and its courts have promulgated over the decades. It contains too many ambiguities and external references, and some of the agency interpretations run counter to what a layperson might understand as the natural or most obvious meaning of the text.
Many contractors have quite a bit of experience in managing project failures -- either succeeding just enough to encourage the customer to throw good money after bad, or highlighting the less disastrous results in order to explain why the next contract will succeed where the last one failed.
The same is true for most non-government contractors who work on large, one-of-a-kind contracts. The fundamental reason those projects are hard to predict, hard to manage, and hard to fix is that they tend to be very complicated and significantly different than what people have done before. Those differences from previous experience make it hard to figure out in advance where a given project will behave differently than previous jobs, and lend themselves to just-so stories when it comes to explaining the failures (no matter whether that explanation comes with positive or negative spin).
That approach works well if you're selling many, many copies of your software, or if the customer representative is intimately familiar with the customer's actual needs. For most more specialized development efforts, having a customer representative ends up adding a middleman, confusion and extra work.
What is the difference to actual development between "we have a launchable product after each sprint" versus "we launch our product after each sprint"? There are obvious differences to the users, but what makes the former superior to the latter when it comes to meeting the overall project goals?
Also, there are a lot of non-agile alternatives, many of which do (or can) incorporate periodic release-candidate checkpoints. It is simply not accurate to talk about "the" non-agile alternative.
While no process will reliably produce good software with a dysfunctional team, Agile seems to be much more sensitive to dysfunction than many other processes. If you have a team full of disciplined, skillful individuals led with integrity by focused managers, many well-documented software processes will let you deliver good software on schedule. In the real world, teams often fall short of that ideal, so it is important for a development method to be somewhat robust to imperfect use, but Agile seems to encourage frequent distractions and excessive back-and-forth.
Funnily enough, most (academic) software engineering researchers understand that "waterfall" was originally intended as an exaggerated -- strawman -- description of a methodology that nobody uses in practice. Most practitioners also understand that any non-trivial project involves some backtracking, and most involve some iteration on parts of the development lifecycle, and thus don't try to use a strict waterfall method. Most Agilistas didn't get either memo.
Your outline of running a software project applies equally well to a spiral method or a CMMI-compliant method or a lot of ad hoc methods without using any defined process. The practical problems with Agile are in the details that you glossed over that distinguish Agile from those alternative methods. Those other methods are not always better than Agile, but Agile is not always better -- and is frequently worse -- than them.
One of the hardest things for process designers to do is to fit their processes to the people who will use them.
Most hard-core proponents of Agile don't understand this. This shows up in the small number of places that do stand-up meetings right, that do automated *and* thorough testing right, that elicit useful input and direction from the customer, and so forth. Once you throw all the Agile processes together, few places can do most of it right, and that's one of the biggest reasons that Agile ends up being a poor fit so often.
When projects inevitably fail in those circumstances, it is just annoying human behavior that makes the Agilistas claim the failure is due to not doing Agile hard enough rather than doing Agile in the first place, and that's one of the biggest reasons that Agilistas end up being obnoxious blowhards so often.
Agile dictates that you have practically continuous customer input to the development process. How do you propose to get that -- and to communicate your expectations about those interactions with the customer -- without telling them about the methodology?
Journals and conferences don't want to publish negative results, so you very seldom hear about all the people who try a process and find that it sucks for them.
Process success stories in the software field have always been driven more by special circumstances than science. Nobody has yet figured out how to (or at least bothered to) control for variations in sample-group productivity well enough to generate reproducible results for most process changes, and all the practitioners want to optimize their processes for different things. For example, CMMI and its ancestors are good if you have a load of time, good requirements control, and a few good leaders mixed with a bunch of more ordinary workers; Agile is good if your customers value whims over checking all the boxes and having really robust software; etc.
Finally, software changes can have chaotic effects, which makes it hard to apply a lot of the control, prediction and robustness methods used in other engineering fields. This makes me think that there will always be a large element of individual skill and domain expertise in building and delivering successful software, and that processes will always need to be carefully chosen based on the team and the project.
If you're not doing Xtreme Agile, you're not doing Agile right.
Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.
You don't even have to get that far, you just have to minimally comprehend the bit that the blurb quotes from the article: "Emissions from drilling, including fracking, and leaks from transmission pipes totaled 225 million metric tons of carbon-dioxide equivalents during 2011, second only to power plants".
Contracts signed under duress are often void, as are contracts with unconscionable terms.
Were Aaron Greene and Morgan Gliedman arrested recently for legitimate dissent? Or were they arrested for illegally possessing destructive devices (and apparently planning to use them against others)? Also, don't you find it ironic that OWS is so heavily staffed by children of privilege like those two?
So your argument is that "cost of physically performing" really means the same thing as "cost of performing", and that the FSF included the word "physically" for no reason? Somehow I'm not terribly convinced.
Labor costs would generally be reasonable, but the license apparently bars rolling those in. If you don't like that, take it up with the FSF.
He was already in violation; he did not include either the source code or a written offer to provide source code with his binary version. If the binary version was accompanied by the source code, that would have ended his obligations; if it was accompanied by a written offer to provide source code, that would allow anyone to ask for the source code.
You obviously either never read the GPL or misunderstood it. It does not require one to possess a binary copy as a prerequisite for anything.
Here, let me exchange the White House for you.
Do you see the difference between providing the medium and providing a link to it?
There are at least three problems with your interpretation. First, the binary form of the software appears to not include any offer to provide source code, so the $3.99 cost for a binary copy is not easily interpreted as the cost to provide a copy of the source code. Second, the language of the GPL specifically limits the cost to the "cost of physically performing source distribution"; the inclusion of the qualifier "physically" arguably excludes imputed labor costs. Third, to the extent that the language is ambiguous, US courts are supposed to interpret ambiguous clauses in standard form contracts against the party offering the contract, and there is room to view the distributor either as the party who accepted the GPL or the party who offered it (to the end user).
I sent a support request to the distributor asking where the source code is. Depending on the response to that, I might complain to Google and/or the DosBox developers. I would rather have the distributor mend his ways with as little third-party pressure as possible; I think that usually leads to a better FOSS environment in the long term.
I paid $3.99 for a copy, but that still does not give me any legal rights under the GPL; the GPL is between a distributor (the DOSBox Turbo guy) and the authors (contributors to DosBox) of a piece of software. The issue is that the distributor has not satisfied the terms of the license that allows him to create and distribute his derived work -- those do not allow him to sell binary copies and then only give source to people who paid for the binary.