Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re: Likely misdemeanor mishandling of classified i (Score 1) 425 425

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.

Comment Re: Likely misdemeanor mishandling of classified i (Score 2) 425 425

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.

Comment Re:How does it hurt academic research? (Score 1) 101 101

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.

Comment Re: Sort of.. (Score 1) 86 86

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?

Comment Re:No. (Score 1) 507 507

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.

Comment Re:No. (Score 1) 507 507

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.

Comment Re: No. (Score 1) 507 507

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.

Comment Re:No. (Score 1) 507 507

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.

Comment Re:No. (Score 1) 507 507

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.

Comment Re:No. (Score 1) 507 507

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.

Comment Re:No. (Score 1) 507 507

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.

Comment Re:No. (Score 1) 507 507

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.

Comment Re:No. (Score 1) 507 507

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.

Sometimes, too long is too long. - Joe Crowe