Does "make out with" mean sexual intercourse where you come from? I understand it to mean kissing and perhaps groping. Still not something you should falsely accuse a teacher of doing with a minor, but kissing is not as serious a violation as full on intercourse.
What is your point about Amb. Gration? That he had at least five other bone-headed practices, so violating the Federal Records Act is not really an offense worth caring about? Even if true, does this help an official who presented Russia with an "overcharge" button for diplomacy, who wanted to obscure the events leading up to Benghazi because she pretended to not see what difference it would make to understand the truth, and who flagrantly violated State Department policy while her immediate underling was persecuting an ambassador for violating that same policy?
Perhaps Colin Powell also violated the Federal Records Act. State Department policy did not officially require use of government email servers (except in emergency situations) until the year he left the office. If he wants to run for president, there should certainly be a public debate over what he did or didn't do with regards to that. However, his primary defense -- that most of his emails were sent to government addresses -- is also Hillary Clinton's primary defense.
I did not directly address your facile arguments about what a foreign government would want from a Cabinet secretary's email because I thought the holes were so obvious: Hacking her server would give far more information than they could capture from a single conversation in her house, it is easier to do deniably, and at any rate the undeniable breach of federal law is in failing to put federal records in proper custody for preservation and oversight. For high-level officials, mishandling classified and SBU information is a real risk (and what the IGs here want to be investigated), but is not such a clear violation.
The law requiring official records to be retained for future reference and use was, like all statutes, passed by Congress and signed by the President. HRC also fired an ambassador for keeping email on a non-government server, so she knew what the rules were. She just didn't think she should have to follow them -- and the Obama DOJ apparently agrees that she is too good for our laws to apply to her.
At least in CS, most research in journals is hardly relevant the real world, and most of it is largely redundant with what the authors could get published in other venues. Both of those pathologies are due mostly to incentives in academia to publish or perish. Corporate researchers have incentives to describe their research and move on, not milk their one decent idea (and funding stream) until it is dry. Looking at the organizational affiliations of published papers' authors does not say much about where relevant research is done.
On top of that, the more of these things you expect to deploy, the better an investment in test and verification amortizes. How much does the testing cost, and how long does it take someone to replace a failed system, and how many replacements does it take before the operations cost exceeds the verification cost?
Sounds like a typical offshoring disaster. I hope somebody somewhere up the command chain felt the consequences.
I've also had luck with waterfall-like development models, on projects from six months to about four years (although the four-year project did have three distinct iterations in order to manage risk). That was for a vehicle-mounted sensor to detect land mines, so there were obvious reliability concerns -- and we could meet them because waterfall let us budget time for detailed failure mode analyses, rather than trying to make that fulfill some user story within a single sprint.
Of course you would say that. You would still be wrong. What you call "organizational dysfunctions" -- but everyone else would call "a normal mix of people" -- can be handled more effectively under a waterfall-like process than under an Agile one. That doesn't make it less efficient.
If you want the same kinds and amount of work product (including detailed requirements, design documents, formal verification, etc.), Agile is likely to be less efficient because you start lots of developers writing code before anyone has a good grip on what the project should look like -- and they continue working furiously until the end. It looks nice because you have something to show and everybody is busy, but the something doesn't fit the need and you're burning through your budget.
Telling people what is blocking your progress *is* pointing fingers, friend.
Waterfall does not need that many long meetings. Instead of five 15-minute scrums in a week, I've typically had one 30- to 40-minute status meeting in a week.
Waterfall does not require the users to know in advance exactly what they want. Why do agilistas spout that nonsense (beyond it being part of the creed)?
If your project leads -- managers, systems engineers, whoever deals with the customer most -- do not know how to deal with vague requirements, irrational schedules, or requirements changes, your project is going to fail regardless of methodology. Agile exacerbates and encourages those problems.
Successful waterfall does not have the problem you claim with requirements elicitation because that is part of what a good system engineer does. I guess agilistas have never worked with good systems engineers. Unless the customer is a professional software developer, it is natural that he or she can't explain their business requirements in the kind of detail that is needed to guide software development and testing. The development team can still develop "use cases" (IMO a more cumbersome, but clearer, term than "stories" -- but basically the same thing) and refine them enough for developers to use.
Waterfall is fragile to change only to the extent that the project is mismanaged -- yet when agile is mismanaged, it fails more spectacularly than waterfall. Agile is designed to make a more convincing appearance of progress, but it is also designed to throw more code away.
Put as much lipstick on that pig as you want, but it's still going to squeal.
A functional waterfall-style team needs two people to be good at their jobs: A manager (to keep everyone pointed in the same direction) and a system engineer (to make sure that direction is a good one). By your argument, a functional agile-style team needs almost everyone to be good. Most teams aren't like that, and the ones that are will do pretty well with any methodology.
Where did you go during that six months, and did the team's manager get fired for not doing his or her job?
If developers are not allowed to add their own bugs or issues, then either your team is too big for agile or the project is too small for your team. Instead of prohibiting that, somebody needs to oversee all the bugs and issues that get added, and part of their job should be to provide feedback when anybody submits an issue report that is not well-aligned with the customer's or user's interests.
How do you square that advice with the agile advocacy of incremental development starting with a minimal prototype? Anybody who thinks about it objectively realizes that you don't want a mock-up to be backed by anything like your final code, but Agile strongly calls for developing a minimal app that can finish user stories -- and then solving more stories by extending that code. That conflicts with the first pass being a mock-up that you expect to extensively rework.
What's actually documented is that big software projects have a high probability of failure. The level of detail in their requirements is, like the failure rate, a consequence of size.
Agile seems mostly like it is meant to let developers write more prototypes, with the expectation of throwing them away, in the name of "responding to change" -- particularly when, as often as not, the change is due to defects in the development process rather than any underlying technical or business reason. Instead of planning, there's a frivolous focus on making things that look good or check some box but don't necessarily have a solid architecture.
You are basically just saying that agile is more *fr*agile than waterfall -- given two teams of equal "discipline" and skill, you're likely to have something closer to the original intention with waterfall than with agile, because (in your words) agile requires more discipline to work well. Also, you're spouting nonsense when you say that the point of daily meetings is to free managers from micro-managing; if they wanted to stop micro-managing, they would not have a meeting each day where the explicit purpose is to point fingers.
Waterfall doesn't need a long QA/QC cycle if you put thought into design validation and verification beforehand, and spend some time developing tests in parallel with developing code. Putting off test planning and preparation will hose you whether you use waterfall or agile or whatever else.
Facebook was a typo. Please excuse my brain for substituting one social networking site for another one. Do you get so easily butthurt because you're an oversensitive moron, or because you're a troll?
I know perfectly well why it's a stupid thing to do, regardless of whether one has a security clearance or even any significant access to trade secrets, export-controlled materials, or anything similar. I can't convince strangers about that, though, and I haven't been on the receiving end of such spam, so I don't have a solution for the general problem. I do think it is spectacularly stupid to jump, as you did, from "LinkedIn has an entirely optional way for you to give them control of your email" to "DOD employees should not be allowed to use FaceBook, period". My way of fighting that particular stupidity is to call you on it.
Are you getting those invitations from people with security clearances? If so, try letting their security officers know -- security@example.org, or whatever domain name they used. They will almost certainly get a dressing down, will probably get written up, and everyone else at the site or company will get a sternly worded reminder (in addition to their annual training) never to share their passwords with anyone, for any reason.
You complain loudly that people with clearances shouldn't do that, but so far you have not even asserted that they have done that -- only that some people on the Internet do -- much less provided so much as an anecdote to convince anyone that they gave their password to LinkedIn. That's most of why I called you and your argument stupid. The other part is that you jumped straight from "LinkedIn lets you do something stupid" to "I simply cannot fathom any DOD employees being allowed to use LinkedIn, period", and that's missing a whole chain of implications to support the conclusion.
DC has a moderate number of non-cleared (and even mostly unrelated to government) jobs in IT and engineering. They pay much closer to the national average. A while back, a recruiter I talked to seemed very surprised that a software development manager with 10 years of progressively advancing experience and a secret (not TS or poly) clearance could make $140k/year. Salary-survey web sites seem to say IT and engineering fields average $100k-$120k/year, which seems low to me; maybe I haven't looked at all the non-government-related jobs enough.
What do friendly countries do when they have US citizens working in facilities or on systems that the friendly countries have classified? There is probably a quite elaborate (social/management) protocol for reciprocating security clearances, supplemental background checks if deemed appropriate, and who knows what else. There would not be much point in distinguishing between "releasable to (country list)" and "not releasable to foreign citizens" without something like that.
You must be one of those stupid people who are going to be stupid, because as someone else explained to you even before my earlier comment, LinkedIn does not require its users to submit any password for any email account. You are making entirely unwarranted (and stupid) assumptions about what other people have done, and then using those faulty assumptions to argue about what people should be allowed to do.
The stereotypical reason to offshore a job is to reduce costs, so pointing out that offshoring these jobs would increase costs is not a tangent -- it's an explanation of why they are unlikely to be offshored. Besides, that BAE Systems logo doesn't mean that it was developed outside the US. BAE owns a huge number of US locations, which are operated mostly independently by a subsidiary incorporated in the US.
Companies don't automatically make profits. You can start a new business, but you are still going to face competition from overseas. Most new businesses fail, and those that don't require the founder(s) to stay super-busy for quite a few years before the business starts to operate well. Of course, it might never operate that well; the owner might make less than they did before, but just have more control over their schedule and work. Starting your own business neither prevents offshore competition nor ensures financial success.
Slashdot Mirror
Does "make out with" mean sexual intercourse where you come from? I understand it to mean kissing and perhaps groping. Still not something you should falsely accuse a teacher of doing with a minor, but kissing is not as serious a violation as full on intercourse.
The criminal law you quoted was voided in May as unconditional. It was not even close to comporting with the First Amendment.
What is your point about Amb. Gration? That he had at least five other bone-headed practices, so violating the Federal Records Act is not really an offense worth caring about? Even if true, does this help an official who presented Russia with an "overcharge" button for diplomacy, who wanted to obscure the events leading up to Benghazi because she pretended to not see what difference it would make to understand the truth, and who flagrantly violated State Department policy while her immediate underling was persecuting an ambassador for violating that same policy?
Perhaps Colin Powell also violated the Federal Records Act. State Department policy did not officially require use of government email servers (except in emergency situations) until the year he left the office. If he wants to run for president, there should certainly be a public debate over what he did or didn't do with regards to that. However, his primary defense -- that most of his emails were sent to government addresses -- is also Hillary Clinton's primary defense.
I did not directly address your facile arguments about what a foreign government would want from a Cabinet secretary's email because I thought the holes were so obvious: Hacking her server would give far more information than they could capture from a single conversation in her house, it is easier to do deniably, and at any rate the undeniable breach of federal law is in failing to put federal records in proper custody for preservation and oversight. For high-level officials, mishandling classified and SBU information is a real risk (and what the IGs here want to be investigated), but is not such a clear violation.
The law requiring official records to be retained for future reference and use was, like all statutes, passed by Congress and signed by the President. HRC also fired an ambassador for keeping email on a non-government server, so she knew what the rules were. She just didn't think she should have to follow them -- and the Obama DOJ apparently agrees that she is too good for our laws to apply to her.
At least in CS, most research in journals is hardly relevant the real world, and most of it is largely redundant with what the authors could get published in other venues. Both of those pathologies are due mostly to incentives in academia to publish or perish. Corporate researchers have incentives to describe their research and move on, not milk their one decent idea (and funding stream) until it is dry. Looking at the organizational affiliations of published papers' authors does not say much about where relevant research is done.
On top of that, the more of these things you expect to deploy, the better an investment in test and verification amortizes. How much does the testing cost, and how long does it take someone to replace a failed system, and how many replacements does it take before the operations cost exceeds the verification cost?
Being able to replace the default Start menu (or entire initial screen) does not excuse the default being so awful.
Sounds like a typical offshoring disaster. I hope somebody somewhere up the command chain felt the consequences.
I've also had luck with waterfall-like development models, on projects from six months to about four years (although the four-year project did have three distinct iterations in order to manage risk). That was for a vehicle-mounted sensor to detect land mines, so there were obvious reliability concerns -- and we could meet them because waterfall let us budget time for detailed failure mode analyses, rather than trying to make that fulfill some user story within a single sprint.
Of course you would say that. You would still be wrong. What you call "organizational dysfunctions" -- but everyone else would call "a normal mix of people" -- can be handled more effectively under a waterfall-like process than under an Agile one. That doesn't make it less efficient.
If you want the same kinds and amount of work product (including detailed requirements, design documents, formal verification, etc.), Agile is likely to be less efficient because you start lots of developers writing code before anyone has a good grip on what the project should look like -- and they continue working furiously until the end. It looks nice because you have something to show and everybody is busy, but the something doesn't fit the need and you're burning through your budget.
Telling people what is blocking your progress *is* pointing fingers, friend.
Waterfall does not need that many long meetings. Instead of five 15-minute scrums in a week, I've typically had one 30- to 40-minute status meeting in a week.
Waterfall does not require the users to know in advance exactly what they want. Why do agilistas spout that nonsense (beyond it being part of the creed)?
If your project leads -- managers, systems engineers, whoever deals with the customer most -- do not know how to deal with vague requirements, irrational schedules, or requirements changes, your project is going to fail regardless of methodology. Agile exacerbates and encourages those problems.
Successful waterfall does not have the problem you claim with requirements elicitation because that is part of what a good system engineer does. I guess agilistas have never worked with good systems engineers. Unless the customer is a professional software developer, it is natural that he or she can't explain their business requirements in the kind of detail that is needed to guide software development and testing. The development team can still develop "use cases" (IMO a more cumbersome, but clearer, term than "stories" -- but basically the same thing) and refine them enough for developers to use.
Waterfall is fragile to change only to the extent that the project is mismanaged -- yet when agile is mismanaged, it fails more spectacularly than waterfall. Agile is designed to make a more convincing appearance of progress, but it is also designed to throw more code away.
Put as much lipstick on that pig as you want, but it's still going to squeal.
A functional waterfall-style team needs two people to be good at their jobs: A manager (to keep everyone pointed in the same direction) and a system engineer (to make sure that direction is a good one). By your argument, a functional agile-style team needs almost everyone to be good. Most teams aren't like that, and the ones that are will do pretty well with any methodology.
Where did you go during that six months, and did the team's manager get fired for not doing his or her job?
If developers are not allowed to add their own bugs or issues, then either your team is too big for agile or the project is too small for your team. Instead of prohibiting that, somebody needs to oversee all the bugs and issues that get added, and part of their job should be to provide feedback when anybody submits an issue report that is not well-aligned with the customer's or user's interests.
How do you square that advice with the agile advocacy of incremental development starting with a minimal prototype? Anybody who thinks about it objectively realizes that you don't want a mock-up to be backed by anything like your final code, but Agile strongly calls for developing a minimal app that can finish user stories -- and then solving more stories by extending that code. That conflicts with the first pass being a mock-up that you expect to extensively rework.
What's actually documented is that big software projects have a high probability of failure. The level of detail in their requirements is, like the failure rate, a consequence of size.
Agile seems mostly like it is meant to let developers write more prototypes, with the expectation of throwing them away, in the name of "responding to change" -- particularly when, as often as not, the change is due to defects in the development process rather than any underlying technical or business reason. Instead of planning, there's a frivolous focus on making things that look good or check some box but don't necessarily have a solid architecture.
You are basically just saying that agile is more *fr*agile than waterfall -- given two teams of equal "discipline" and skill, you're likely to have something closer to the original intention with waterfall than with agile, because (in your words) agile requires more discipline to work well. Also, you're spouting nonsense when you say that the point of daily meetings is to free managers from micro-managing; if they wanted to stop micro-managing, they would not have a meeting each day where the explicit purpose is to point fingers.
Waterfall doesn't need a long QA/QC cycle if you put thought into design validation and verification beforehand, and spend some time developing tests in parallel with developing code. Putting off test planning and preparation will hose you whether you use waterfall or agile or whatever else.
More to the point, who outside Apple develops embedded software for an Apple platform?
I apparently know better than you what a typo is.
I regret thinking you had any intention of arguing in good faith, and shall not make that mistake again.
Facebook was a typo. Please excuse my brain for substituting one social networking site for another one. Do you get so easily butthurt because you're an oversensitive moron, or because you're a troll?
I know perfectly well why it's a stupid thing to do, regardless of whether one has a security clearance or even any significant access to trade secrets, export-controlled materials, or anything similar. I can't convince strangers about that, though, and I haven't been on the receiving end of such spam, so I don't have a solution for the general problem. I do think it is spectacularly stupid to jump, as you did, from "LinkedIn has an entirely optional way for you to give them control of your email" to "DOD employees should not be allowed to use FaceBook, period". My way of fighting that particular stupidity is to call you on it.
Are you getting those invitations from people with security clearances? If so, try letting their security officers know -- security@example.org, or whatever domain name they used. They will almost certainly get a dressing down, will probably get written up, and everyone else at the site or company will get a sternly worded reminder (in addition to their annual training) never to share their passwords with anyone, for any reason.
You complain loudly that people with clearances shouldn't do that, but so far you have not even asserted that they have done that -- only that some people on the Internet do -- much less provided so much as an anecdote to convince anyone that they gave their password to LinkedIn. That's most of why I called you and your argument stupid. The other part is that you jumped straight from "LinkedIn lets you do something stupid" to "I simply cannot fathom any DOD employees being allowed to use LinkedIn, period", and that's missing a whole chain of implications to support the conclusion.
DC has a moderate number of non-cleared (and even mostly unrelated to government) jobs in IT and engineering. They pay much closer to the national average. A while back, a recruiter I talked to seemed very surprised that a software development manager with 10 years of progressively advancing experience and a secret (not TS or poly) clearance could make $140k/year. Salary-survey web sites seem to say IT and engineering fields average $100k-$120k/year, which seems low to me; maybe I haven't looked at all the non-government-related jobs enough.
What do friendly countries do when they have US citizens working in facilities or on systems that the friendly countries have classified? There is probably a quite elaborate (social/management) protocol for reciprocating security clearances, supplemental background checks if deemed appropriate, and who knows what else. There would not be much point in distinguishing between "releasable to (country list)" and "not releasable to foreign citizens" without something like that.
You must be one of those stupid people who are going to be stupid, because as someone else explained to you even before my earlier comment, LinkedIn does not require its users to submit any password for any email account. You are making entirely unwarranted (and stupid) assumptions about what other people have done, and then using those faulty assumptions to argue about what people should be allowed to do.
The stereotypical reason to offshore a job is to reduce costs, so pointing out that offshoring these jobs would increase costs is not a tangent -- it's an explanation of why they are unlikely to be offshored. Besides, that BAE Systems logo doesn't mean that it was developed outside the US. BAE owns a huge number of US locations, which are operated mostly independently by a subsidiary incorporated in the US.
Companies don't automatically make profits. You can start a new business, but you are still going to face competition from overseas. Most new businesses fail, and those that don't require the founder(s) to stay super-busy for quite a few years before the business starts to operate well. Of course, it might never operate that well; the owner might make less than they did before, but just have more control over their schedule and work. Starting your own business neither prevents offshore competition nor ensures financial success.