It also makes the owners of Facebook and Farmville very, very rich, so I don't think they care very much if their wide demographic fits your particular definition of "gamer".
This will surprise precisely no one who's ever done business. Of COURSE you don't spend any effort on the people that would stick with you anyway or that do not really impact the (short-term) bottom line. Why waste good time and money on them? Spend it on the big guys that might actually harm your business if they up and leave.
After all, you only need to last the quarter, then cash in your options and leave.
Except that the BSG ending was pretty much made up on the spot and the writers had NO idea that the Final Five idea would take off so hard, so they actually had to ploink faces to the concept late in the story.
E.g., Ron Moore:
It was somewhere in the course of the third season [that the possibility was first raised.] We killed Ellen early that season and we didn’t have an inkling of that at that point. But at the point that we killed Ellen, around the same time frame, I was starting to come up with the idea that there were five Cylons that had yet to be revealed.
These are the detailed-oriented people who become fixated on minutae that they can't see big picture stuff.
And these are exactly the people that make really excellent coders. Or to put it another way: your developers are extremely likely to mostly be like this.
A well-designed architecture (up-front in non-agile, defined in the first few iterations in sane agile) can also help, because you know your modules are well-separated and isolated, and there are not so many paths to check for change impact / risk management.
Upshot is: just because the agile manifesto doesn't define it, doesn't mean you can get away with no documentation, no risk management, no traceability, no change management, or in fact no responsibility at all. I don't really think that was the original intention of agile anyway, but it sure is the most popular interpretation.
Wow...so when did cancelling a project mean that it was a failure? In fact, I would say some of the biggest successes that I have seen are when a team/group/department/company has enough guts to admit that they aren't going to get value out of the project and shut it down. The earlier the more successful.
You must live an economically sheltered life. In the real world, project success is defined by the project earning more money than it cost.
And no, "money not spent" isn't money earned, because every project you don't even consider doing is "money not spent".
Don't get me wrong, I know what you mean - sometimes you know that the only real valid choice is to kill it (with fire, or from orbit), but that just turns a potentially massive failure into a tiny failure.
There's a huge grey zone with the actual Real World in it between "deciding everything up front" which is what Agilists say the iterative waterfall process does, and "allowing everything to change" which is what the CMM L5 claim Agile/agile is about.
Yes, some things should be able to change.
No, some other things should NOT be allowed to change without a complete project renegotiation.
You guys without an external paying client can open your eyes again now.
There have been some developments since Brooks wrote No Silver Bullet that have helped by attacking the accidental complexity of software development - widespread use of garbage collection, for instance. But Brooks is still absolutely correct that the complexities of software have a lot more to do with the complexities of the human mental modeling, heuristics, and decisions that software replaces than they do with the challenge of converting that to something the computer can understand.
Oh man, wrong tree:)
I'm involved in a.NET to native wrapping project, and I'm NOT friends with the garbage collector right now.
I wasn't really referring to the detail of Brooks' essay, just the overall idea that there is no silver bullet to make solving hard problems easy. The "hard problems" are the things that have not been done before that our customers are asking us to develop.
In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.
This is exactly one of the key points that the Agile community keep trying to drill into us! The Agile Manifesto explicitly states "Responding to change over following a plan", which is translated into the principle "Welcome changing requirements, even late in development."
If you drill down, the original quote basically means that Agilists (big-A) are defining "their process" as "whatever you're doing that is actually working, THAT's Agile man, keep doing it! I'll take my consultancy fee now.".
Meanwhile the rest of the world is just trying to get the job done, trying not to waste time in "methodologies", but us old fogeys keep having to explain to the new guys that we've *tried* all this stuff, and what we are already doing is what works for us.
"You are doing it wrong" is the perpetual excuse of Agilists when you say that agile methods have not worked for you. They are hiding behind a certain impossible to define or explain "something" that you supposedly are not doing or not doing right that causes your project to fail, because if you were Doing Agile Right (tm) (whatever that means) your project would have been a resounding success.
In the end Fred Brooks got it right decades ago: "there is no silver bullet". Software development is just hard. Anything promising massive gains in success or effectiveness is snake oil.
Quoth TFA: "Despite potential pitfalls, experts in the agile space agree that implementation of agile practices has benefited software development overall."
And in other news, despite potential pitfalls, the pope agrees that Catholicism has benefited religion overall.
There are some that say there is no such thing as bad publicity.
However, I will now NOT be buying StarCraft2, or Diablo 3 after this. It will also stop me from buying Civ5, because once again it's demonstrated that *requiring* network access even for the single player game is really just a back door for disabling something you've already pay for based on all kinds of arbitrary reasons.
Slashdot Mirror
It also makes the owners of Facebook and Farmville very, very rich, so I don't think they care very much if their wide demographic fits your particular definition of "gamer".
I prefer four-by-four.
Never underestimate the stopping-power of a well-aimed car.
Glad someone at least RTFP ;-).
This will surprise precisely no one who's ever done business. Of COURSE you don't spend any effort on the people that would stick with you anyway or that do not really impact the (short-term) bottom line. Why waste good time and money on them? Spend it on the big guys that might actually harm your business if they up and leave.
After all, you only need to last the quarter, then cash in your options and leave.
And promptly got himself killed at the next zebra crossing, unfortunately.
Time is an illusion.
Lunchtime doubly so.
E.g., Ron Moore:
It was somewhere in the course of the third season [that the possibility was first raised.] We killed Ellen early that season and we didn’t have an inkling of that at that point. But at the point that we killed Ellen, around the same time frame, I was starting to come up with the idea that there were five Cylons that had yet to be revealed.
These are the detailed-oriented people who become fixated on minutae that they can't see big picture stuff.
And these are exactly the people that make really excellent coders. Or to put it another way: your developers are extremely likely to mostly be like this.
A well-designed architecture (up-front in non-agile, defined in the first few iterations in sane agile) can also help, because you know your modules are well-separated and isolated, and there are not so many paths to check for change impact / risk management.
Upshot is: just because the agile manifesto doesn't define it, doesn't mean you can get away with no documentation, no risk management, no traceability, no change management, or in fact no responsibility at all. I don't really think that was the original intention of agile anyway, but it sure is the most popular interpretation.
Wow...so when did cancelling a project mean that it was a failure? In fact, I would say some of the biggest successes that I have seen are when a team/group/department/company has enough guts to admit that they aren't going to get value out of the project and shut it down. The earlier the more successful.
You must live an economically sheltered life. In the real world, project success is defined by the project earning more money than it cost.
And no, "money not spent" isn't money earned, because every project you don't even consider doing is "money not spent".
Don't get me wrong, I know what you mean - sometimes you know that the only real valid choice is to kill it (with fire, or from orbit), but that just turns a potentially massive failure into a tiny failure.
There's a huge grey zone with the actual Real World in it between "deciding everything up front" which is what Agilists say the iterative waterfall process does, and "allowing everything to change" which is what the CMM L5 claim Agile/agile is about.
Yes, some things should be able to change.
No, some other things should NOT be allowed to change without a complete project renegotiation.
You guys without an external paying client can open your eyes again now.
I'm anti-agile in principle, but even I know that you don't ship every iteration - you create a potentially shippable product every iteration.
Therefore, it is always doomed to failure, since at least one of those will always be true.
The most successful model will be one that assumes all of those are going to be true.
That's probably the most succinct formulation of the problem and the proper path to a solution I've seen. Well done.
Well, yes and no.
There have been some developments since Brooks wrote No Silver Bullet that have helped by attacking the accidental complexity of software development - widespread use of garbage collection, for instance. But Brooks is still absolutely correct that the complexities of software have a lot more to do with the complexities of the human mental modeling, heuristics, and decisions that software replaces than they do with the challenge of converting that to something the computer can understand.
Oh man, wrong tree :) .NET to native wrapping project, and I'm NOT friends with the garbage collector right now.
I'm involved in a
I wasn't really referring to the detail of Brooks' essay, just the overall idea that there is no silver bullet to make solving hard problems easy. The "hard problems" are the things that have not been done before that our customers are asking us to develop.
In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.
This is exactly one of the key points that the Agile community keep trying to drill into us! The Agile Manifesto explicitly states "Responding to change over following a plan", which is translated into the principle "Welcome changing requirements, even late in development."
If you drill down, the original quote basically means that Agilists (big-A) are defining "their process" as "whatever you're doing that is actually working, THAT's Agile man, keep doing it! I'll take my consultancy fee now.".
Meanwhile the rest of the world is just trying to get the job done, trying not to waste time in "methodologies", but us old fogeys keep having to explain to the new guys that we've *tried* all this stuff, and what we are already doing is what works for us.
"You are doing it wrong" is the perpetual excuse of Agilists when you say that agile methods have not worked for you. They are hiding behind a certain impossible to define or explain "something" that you supposedly are not doing or not doing right that causes your project to fail, because if you were Doing Agile Right (tm) (whatever that means) your project would have been a resounding success.
In the end Fred Brooks got it right decades ago: "there is no silver bullet". Software development is just hard. Anything promising massive gains in success or effectiveness is snake oil.
Quoth TFA: "Despite potential pitfalls, experts in the agile space agree that implementation of agile practices has benefited software development overall."
And in other news, despite potential pitfalls, the pope agrees that Catholicism has benefited religion overall.
You elected the senate. They are your "public approval".
There are some that say there is no such thing as bad publicity.
However, I will now NOT be buying StarCraft2, or Diablo 3 after this. It will also stop me from buying Civ5, because once again it's demonstrated that *requiring* network access even for the single player game is really just a back door for disabling something you've already pay for based on all kinds of arbitrary reasons.
Or you have to think up a way to analyze any strategy generically and come up with a possible counter.
The operators give us a standard naming convention.
And by "standard" you mean:
Robert S. Mueller, III just shared "Which kind of terrorist are you?" application with you. Take the survey now?
How often is it that you don't use an electronic device for YEARS(!!!!!) but suddenly care about it being immediately available?
Ironically, for calculators, every single time I use one.
You mean any excel sheet in a shared folder on the network.