Actually that requirement goes away almost instantly the moment your army is up against any real contest.
That's been true throughout all of history and has never been more true today where we simply relabel anyone killed by our weapons, "enemy combatants". PR problem solved.
Actual work isn't simple, at least on a computer. Anything simple on a computer gets automated out of being someone's job.
Finder...don't even get me started. It's hands down the worst file manager ever to exist on any system. Completely incapable of actually doing it's core task of managing files. It's one of the first things every Mac user replaces.
Any setting, hey? How about the setting to simply turn off mouse acceleration? Nope, not in the GUI. This extremely basic, frankly critical setting requires Googling an extremely cryptic command to be entered into Terminal. Intuitive my arse. There's mountains of stuff like this.
A lot of things are "simple" by simply ignoring the need entirely. I frequently have a dozen active connections to various different servers, etc. When I pickup my laptop to walk across the office to a conference I'd prefer to not have to keep the lid precariously open. Nope, sorry, when you close the lid on a Mac it goes into sleep mode. Period. No way to change this simple, extremely common business use case (aside from buying a 3rd party app).
OSX is "simple" because they simply left out a shit ton of common, critical features, large and small. Features that people actually doing work actually need to do that work efficiently. The ONLY use case I've found of actually productive people using OSX are audio/music/video folks. Of course, they spend %0.001 of their time in the OS, the rest of the time they are completely in one or two applications. They simply don't use the OS enough to know or care. At that point there's zero difference for them between OSX and Windows or whatever, aside from the substantial Apple hardware tax.
Installing software I can't argue with, they did nail that pretty well.
Sadly, the built in "Terminal" application is a steaming pile of crap. But hey, why improve it if you're meant to be in the GUI all the time right? Of the literally dozens of terminal apps I've used across a dozen different systems, it only manages to beat out Window's CMD shell for world's worst terminal app. It's one of the first things that needs to be thrown out and replaced to begin to make OSX workable. Right after the world's most pathetic excuse for a file manager, "Finder", that can't even mange it's most basic purpose in life...managing files.
The list goes on and on. Granted, there are good replacements available for pretty much everything in OSX. But there have to be...because practically everything out of the box in OSX is garbage. Hell, for a system that prides itself for the best GUI that has ever existed, something as simple as turning off the train wreck that is mouse acceleration requires you to pull up the Terminal and type in an extremely cryptic command. Huh?
The best feature of OSX is Growl. Growl is a fantastic feature, supported by pretty much everything written for OSX. Except...you know...OSX itself because Growl isn't actually part of OSX, it's a 3rd party program/API!
Fact: Windows 7 + Cygwin is FAR more "Unix" then OSX will ever be (and frankly, makes a better "Unix Workstation" for 99% of use cases then any "real" Unix on the market today).
--
The fact of the matter is anyone walking in the room with a Mac under their arm automatically gets two strikes against them. I've known a few to earn their way back from that, but the vast, vast majority just go on to prove how completely non-productive they actually are.
Which, frankly, is a lot worse. OSX is unquestionably one of the most productivity hostile systems ever created. And it's getting worse on that front, not better.
Windows 8 is arguably moving Windows in the same anti-productivity direction...so it'll be interesting to see how business users feel about it in the not-so-long run.
Unix/Linux has a fantastic opening becoming available to move back to its Unix "workstation" roots. But not if that movement either follows the anti-productivity movement or thinks too outside of the box and is "too different" for people to consider switching to. It'll need to find a middle ground, at least long enough to put down roots.
If my phone vibrates, I want to have the option to get up and take the call outside.
If your phone vibrates, and you get up and climb over half the row of people and block/distract the view of everyone behind you, you're still a huge distraction.
Unless that text message says your wife's in labor or your child has been hit by a car, you're officially an asshole.
If you can't handle being incommunicado for 90 minutes, rent a DVD. You simply shouldn't be in a public theater, that's all there is to it. If it was a stage play chances are you would be physically barred from reentering the theater if you left mid-act for any reason, even if you paid $500 for the seat.
Not much. Inferred cameras and microphones see and hear right through pillows, etc. Not as well, sure, but well enough.
Especially given the fussiness of covering it, uncovering it, etc will be too bothersome for 99.999999% of the owners of the XBox. Which is what they're counting on. Anyone paranoid about it will "simply not buy one".
But not buying one won't be an option for long...
When every TV sold is a "smart TV". When every phone is a "smart phone". When every car is a "smart car". This isn't a paranoid vision of some distant future...this is the reality now for a large and quickly increasing percentage of the market: How many phones sold, of any kind, aren't "smartphones"? How many new laptops, tablets, etc don't have a built-in camera and microphone? How many new cars don't have at least a built-in microphone ("for bluetooth") and some form of ability to phone home?
Being anti-agile does not necessarily make one a lazy ill-disciplined developer. A dev could be anti-agile because... well, perhaps he resents being treated like a child,
If the dev considers collaborating well with others, taking ownership and responsibility of their own talents and shortcomings, being accountable to their team mates. If a dev considers such things to be akin to "treated like a child", perhaps the dev is still a child.
The fact is a lot of developers got into software because they could retreat into their own cave and not have to grow up. Not have to learn to work and play well with others.
Waterfall et al are all about micromanaging a schoolyard full of undisciplined developers. Agile is for adults, it requires a strong sense of personal responsibility that frankly a lot of devs just don't have.
--
The fact is Agile is the polar opposite of micromanaging. And that is why a lot of devs don't like, they can't stand the responsibility.
Why are documentation, training, qa, etc considered "downstream"?
You might hear the terms "scrummerfall" or "waterscrum" to describe your example, all boiling down to trying to wedge Scrum/Agile into a familiar existing process (typically some flavor of waterfall). It's an anti-pattern, a red flag. You're right, it won't work. But it's worse then that because it adopts the worst of everything and the best of nothing...a total disaster of a process.
You need to rethink the entire SDLC, break away from the idea that these are serialized phases. There are ways of doing most all of this in parallel. For example at the start of a sprint QA can be fleshing out the requirements by working out all the what-ifs and edge cases, which (especially given a good test framework) can be quickly transformed into unit tests. They won't pass (little if anything is implemented yet), and that's fine.
By the middle of the sprint the developers should have most of the core functionality complete and will be tackling the backlog of unit tests QA has created, while the QA people are transitioning to ad-hoc testing.
--
Similarly there's a reason why you don't start the sprint by immediately putting the entire sprint backlog into "in progress". You pull off as few as possible, 1 if you can, in priority order. And stick with it until it's Done, before picking up the next. A not-to-subtle reason for this is because for those things that must be serialized (eg, final screenshots for documentation/training), they can get to work earlier.
If your team has 10 items to do in a sprint and has all ten "in progress" at once, the sprint is likely doomed. Along with the above problem of work that must be serialized, you have also greatly increased the risk because now everything must work or likely nothing can be shipped. If however, you got the top 8 done and weren't able to start the last 2...you still have 8 cleanly shippable items and the last 2 can just move to the top of the next sprint. No code needs to be pulled out, no docs rewritten, etc, because those 2 never happened.
And yet the reality is exactly the opposite: Agile methods are by strong people, for strong people. It simply doesn't work with fuckups (be they drone or Rambo).
But you are right, good devs figured out processes that work. And like any good dev, they refined them over time and with insight from others. Eventually distilling the process into a methodology...and they called it Agile.
That's literally where all this came from: Great devs, using skill, experience, and creativity, to come up with the best ways to solve very common problem found in very similar situations. And then field testing and refining those solutions into a science. The fact is projects, people, companies are much more typical then they are unique. They have the same types of people faced with the same types of problems. Only a bad dev would try and reinvent the wheel for each and every situation. A good dev reuses as much as they possibly can, be it tools, patterns, or processes.
-
And there are reasons the scrum is firmly at the same exact time, every single day. A big one is directly addressing your concern about interruption and loss of context. When it's held at a reliable time it's hardly any more of an interruption or loss of context then is the sun rising to start the day.
Yes, this does mean that developers who have become accustom to waking up whenever they feel like it, showing up (or not) at whatever time they like, operating entirely within the vacuum of reality that is the fleeting whims of their own mind and theirs alone. It does mean such developers are not going to take kindly to Agile.
Yet the fact is solid team work is a incredibly huge multiplier, far outweighing even the best "Rambos", and you can't have teamwork with people who don't show up. So I'll take a good developer who has good team work skills over a great developer with no team work skills any day.
Agile isn't a solution to the common problem of ignorant, mediocre management.
Agile empowers good and great people to perform at their best, consistently, even establishing a new benchmark for best. Agile processes are systems by strong people for strong people.
What Agile does not do, is work well with mediocre and/or defective people. It can't solve staffing problems, no matter where in the business food chain they are found (most often at the top).
1) No one is asking you to comment on other people's work, or asking them to comment on yours. Again, that's not what the scrum is for.
2) The fact that you're swimlaned so strongly, with such specialized knowledge, strongly brings into question your assertion that you are keeping up on what your team mates are working on. It suggests you're a collection of Rambos, not a team.
The notion of a team implies teamwork. Occasionally consulting each other is no more team work then occasionally consulting stackoverflow.
And that's why they're now arming the police with the same advanced military gear the army uses. Unlike the army, America's cops have a long and disgustingly proud history of killing their own civilians without remorse.
Yet Scrum doesn't allow for micromanagers, and the daily scrum doesn't allow for any manager to speak or ask questions. At all. No really.
The scrum is for the team. If you just have a collection of developers and not a team, the scrum is pointless. If however, you actually are a team, the scrum is invaluable.
Simple: Keep the team in sync, keep the sprint in perspective, keep the project on target. And less talked about, to keep developers honest.
The fact is a lot can and does happen in just a couple days. If you let your developers all run off to their own corners for days at a time your entire project will be spaghetti almost as fast. This is doubly so for "Rambo" developers and drones, the ones most hostile to daily scrums.
5-15 minutes out of an 8 hour day is hardly a burden if you're actually doing work, and it really should be that quick. The fact is however, often when a developer knows the boss isn't going to talk to them for three days they will play WoW for two days and jam code together for 4. You can get all offended, but it happens...a lot.
It's much harder to goof off for a day or three when you're forced to stand up in front of your entire team and actually profess to their faces what you have (or haven't) gotten done. To commit to actually getting something done that day. The threat of embarrassment alone is enough to keep most from slipping and goofing off. Pride of self and pride of team is a large factor in the large productivity boosts good Agile settings have been able to achieve.
Again, Rambo developers who like to work on their Call of Duty skillz for 4 days, cram a bunch of crap out on the 5th, and pat themselves on the back as if they're some kind of coding god, just aren't a good fit for Agile. They also aren't half the coder they think they are and aren't worth half the salary their company is paying them. And companies are starting to figure that out.
Agile doesn't let you hide....that's the real reason most are hostile to it.
Then why can't people instead send a daily e-mail to you alone as the project manager. Why force everybody together and hear about stuff about which they couldn't care less?
If you truly couldn't care less about what your team is doing, then they aren't your team and/or you're not a team player. You're either a Rambo or a drone, neither of which is a good fit for an Agile team.
And that's fine. Frankly a lot of software developers aren't a good fit for Agile. Many got into software specifically because they prefer to work isolated in a cave and tune everyone else out. They like working remote from a coffee shop or whatever.
That however, doesn't make Agile a bad choice for the project or business, it just makes those developers a bad choice. The fact is there are a great deal of developers in the world who are at least as good as you are plus they are team players, they are able to leverage the power of a good team to boost their own performance and their coworkers to new heights they couldn't achieve on their own.
So you're free to keep pretending you're Rambo, the greatest thing to happen to software since cc. Just as businesses are free to hire someone else who'll ultimately offer them far more value directly and indirectly then you ever will.
In a waterfall scenario the customer most often doesn't see anything tangible until way late in the process. Only then are they able to see the project is off course...and by that time it's way, way off course requiring a large, expensive change.
In an agile scenario the customer sees everything early and often, allowing them to keep the project on course with minor adjustments along the way. Any changes they make late in the process are almost certainly to be a fraction of the size of changes they'd have required late in the cycle of a waterfall project.
Forcing most decisions to the front of the process only ensures that they are either wrong or take so long to make that they are no longer relevant by the time the product can be delivered. How wrong and how irrelevant is proportional to how much, how strict, and how early in the process you mandate decisions be made. This is why waterfall most frequently falls into the trap of delivering, "Exactly what they asked for, but not at all what they want/need".
Agile isn't about not making decisions early. Completely the opposite: Agile is about providing the knowledge required as early as possible to make good decisions. Decisions (aka "changes") are made as early as it is possible to correctly make them...and correct from mistakes as early by discovering them sooner.
By contrast waterfall forces most decisions to be made blindly, all but ensuring they will be very wrong, and only discovered after its much, much too late to do anything about it.
The current "zip gun" design is simply a proof of concept, proving that you can in fact CTRL+P a working, untraceable, undetectable firearm.
It's not dissimilar to the 3d printed large capacity magazines created before it. Although they're already much more practical: A 30 round clip that's cheap/easy enough to simply be thrown away after 1 use doesn't need to reliably fire more then 30 rounds to be fully effective.
The point however, is that it's a zip-gun today...it's a fully working AR-15 or Glock 17 tomorrow, or even a full on mini-gun, or printed caseless ammo. And "tomorrow" isn't a euphemism for "some day far in the future, maybe, but probably not". No, "tomorrow" really is tomorrow. Between advancements in 3D printer tech, advancements in materials, advancements in software, and a whole bunch of people suddenly becoming interested in and buying their own 3D printers...we'll be far, far past "zip-gun" this time next year.
Wake the fuck up. This really does change everything. This bell cannot be unrung. No matter where you sit politically on issues of guns, this is the new reality and any regulations you care to write can't pretend reality is something else if you want them to have any real effect.
Want to ban 30 round clips so bad guys can't fire so many rounds at once as they're marching through an elementrary school? Or ban assault weapons? Or ban silencers? Or require background checks?
Noble intentions, but how's that going to be effective when 3D printers are as common place and easy to use as ink jet photo printers are today?
It's not rocket science, but it's not obvious either. Your chart is frankly insane. Who in the world is going to remember any of that when they're out at a bar?!
"1 standard drink" = 1 shot = 1.5oz of ~80 proof. Find me a bar anywhere in the world that pours only 1.5oz of alcohol into any drink.
There simply is no such thing as "1 standard drink", anywhere in the world. It's a completely invalid unit of measure. It's not even the average drink size: Its official size is significantly smaller then any drink served anywhere.
Are there any women left in America under 120lbs? Or men under 160lbs?
Drink limit charts and such that top out before you even reach the lowest rung of real Americans only confuse people. How many drinks can the average 156lbs women have before reaching 0.05%? And the average 196lbs man? What about the above average (and sadly very, very common) 200+lbs women, 300lbs man? Do you double the recommendations...or do you see that 1 drink is the difference between 120 and 160...so "logically" it's 1 more drink for each 40lbs above the 120lbs floor... So a 300lbs man should be able to drink...5 or 6? A 200 lbs woman should be able to handle 3?
Never mind that what passes for "1 drink" is like the "1 serving" on nutritional info. A typically real drink is easily equivalent to 2-3 "recommended" drinks.
Add the mythical weight specs to the mythical drink sizes and it's little wonder why people are stumbling out of bars thinking they can drive. We told them they could!
I've been to a few rallies. The nutters at the rallies make the online folks look quite reasonable by comparison.
The fact is the Tea Party is nothing more then a front group for a few (very few) billionaires. It was never grass roots, it was never a "movement". It's nothing but a few rich bastards whipping nutters into a frenzy, rattling the screws even looser in the process.
3D printers haven't costs "tens of thousands of dollars" for quite some time: http://store.makerbot.com/3d-printers.html And they aren't hard to use, especially if you're printing someone else's downloaded design.
You're missing the fact the person wanting the gun doesn't need to be the one with the printer. Some gang land arms dealer, who currently sells stolen ("untracable") guns, will be printing untracable guns on demand out of the the trunk of a Pontiac.
Considering the already cheap price of 3D printers and the fact they can print copies of themselves, you're never going to dent criminal use of 3D printing. You're not unringing that bell.
The Tea Party advocates for legislative reform of the tax code and containing spending, not revolts against the government.
Clearly you're following a different Tea Party then I do.
I'm tuned into most of the major Tea Party social networks and the message to overthrow the US Government via armed rebellion is very thinly veiled if it's veiled at all. The supporters sure get the message loud and clear, posting endless comments about it.
They really do believe in an armed overthrow of the US Government. By "take their country back" they really do mean with lethal force. They aren't joking around, they're deadly serious. They really do want to start a 2nd US Civil War.
DRM (in particular always-online DRM) is absolutely essential in combating hackers/exploiters/cheaters/griefers.
Cheaters will always find new cheats. But if you paid $70 for a game and know you'll basically throw that money away (and/or get your entire Steam or whatever account banned from a lot of other games as well), you'll be far less likely to cheat given that each time you're banned you'll have to shell out another $70 to cheat again.
Always-On DRM also combats pirating games, as well as combats hackers in multiplayer games (a huge win for gamers, or can be).
So long as it's largely out of sight and out of mind (such as Steam's), always-on DRM is very much here to stay. It solves too many otherwise impossible problems and introduces practically no legitimate issues (when done well).
Personally I'm much more in a huff over the move away from community modding and towards DLC. $15 for DLC that effectively just adds two or three maps? When all is said and done a game like MW3 ends up costing $150 rather then just $70, for a tiny fraction of the content a mod-friendly game like Counter-Strike offered (it itself, being a community mod of Half-Life).
You're assuming everyone, or even most people, sell their games. You're also ignoring the lost sales of new games as some people opt to buy used copies.
The only ones I've honestly known that sell their games are kids. Kids who only can get mom and dad to buy them two or three games a year. There's much more money in the 20s, 30s adults with their own disposable income...a group that's far less likely to care about the hassle of selling their games and/or enjoy keeping a collection. At the very least they're going to hang on to a game far longer then a month which drastically reduces its resale value.
So while there will be some that are accustom to the buy(day one)/play(through quick)/sell(fast) model and will be impacted by your math, most of those losses will be made up by once-used game purchasers now buying games new.
Slashdot Mirror
Actually that requirement goes away almost instantly the moment your army is up against any real contest.
That's been true throughout all of history and has never been more true today where we simply relabel anyone killed by our weapons, "enemy combatants". PR problem solved.
Actual work isn't simple, at least on a computer. Anything simple on a computer gets automated out of being someone's job.
Finder...don't even get me started. It's hands down the worst file manager ever to exist on any system. Completely incapable of actually doing it's core task of managing files. It's one of the first things every Mac user replaces.
Any setting, hey? How about the setting to simply turn off mouse acceleration? Nope, not in the GUI. This extremely basic, frankly critical setting requires Googling an extremely cryptic command to be entered into Terminal. Intuitive my arse. There's mountains of stuff like this.
A lot of things are "simple" by simply ignoring the need entirely. I frequently have a dozen active connections to various different servers, etc. When I pickup my laptop to walk across the office to a conference I'd prefer to not have to keep the lid precariously open. Nope, sorry, when you close the lid on a Mac it goes into sleep mode. Period. No way to change this simple, extremely common business use case (aside from buying a 3rd party app).
OSX is "simple" because they simply left out a shit ton of common, critical features, large and small. Features that people actually doing work actually need to do that work efficiently. The ONLY use case I've found of actually productive people using OSX are audio/music/video folks. Of course, they spend %0.001 of their time in the OS, the rest of the time they are completely in one or two applications. They simply don't use the OS enough to know or care. At that point there's zero difference for them between OSX and Windows or whatever, aside from the substantial Apple hardware tax.
Installing software I can't argue with, they did nail that pretty well.
Sadly, the built in "Terminal" application is a steaming pile of crap. But hey, why improve it if you're meant to be in the GUI all the time right? Of the literally dozens of terminal apps I've used across a dozen different systems, it only manages to beat out Window's CMD shell for world's worst terminal app. It's one of the first things that needs to be thrown out and replaced to begin to make OSX workable. Right after the world's most pathetic excuse for a file manager, "Finder", that can't even mange it's most basic purpose in life...managing files.
The list goes on and on. Granted, there are good replacements available for pretty much everything in OSX. But there have to be...because practically everything out of the box in OSX is garbage. Hell, for a system that prides itself for the best GUI that has ever existed, something as simple as turning off the train wreck that is mouse acceleration requires you to pull up the Terminal and type in an extremely cryptic command. Huh?
The best feature of OSX is Growl. Growl is a fantastic feature, supported by pretty much everything written for OSX. Except...you know...OSX itself because Growl isn't actually part of OSX, it's a 3rd party program/API!
Fact: Windows 7 + Cygwin is FAR more "Unix" then OSX will ever be (and frankly, makes a better "Unix Workstation" for 99% of use cases then any "real" Unix on the market today).
--
The fact of the matter is anyone walking in the room with a Mac under their arm automatically gets two strikes against them. I've known a few to earn their way back from that, but the vast, vast majority just go on to prove how completely non-productive they actually are.
Which, frankly, is a lot worse. OSX is unquestionably one of the most productivity hostile systems ever created. And it's getting worse on that front, not better.
Windows 8 is arguably moving Windows in the same anti-productivity direction...so it'll be interesting to see how business users feel about it in the not-so-long run.
Unix/Linux has a fantastic opening becoming available to move back to its Unix "workstation" roots. But not if that movement either follows the anti-productivity movement or thinks too outside of the box and is "too different" for people to consider switching to. It'll need to find a middle ground, at least long enough to put down roots.
If your phone vibrates, and you get up and climb over half the row of people and block/distract the view of everyone behind you, you're still a huge distraction.
Unless that text message says your wife's in labor or your child has been hit by a car, you're officially an asshole.
If you can't handle being incommunicado for 90 minutes, rent a DVD. You simply shouldn't be in a public theater, that's all there is to it. If it was a stage play chances are you would be physically barred from reentering the theater if you left mid-act for any reason, even if you paid $500 for the seat.
Seriously, just turn off the fucking phone.
Not much. Inferred cameras and microphones see and hear right through pillows, etc. Not as well, sure, but well enough.
Especially given the fussiness of covering it, uncovering it, etc will be too bothersome for 99.999999% of the owners of the XBox. Which is what they're counting on. Anyone paranoid about it will "simply not buy one".
But not buying one won't be an option for long...
When every TV sold is a "smart TV". When every phone is a "smart phone". When every car is a "smart car". This isn't a paranoid vision of some distant future...this is the reality now for a large and quickly increasing percentage of the market: How many phones sold, of any kind, aren't "smartphones"? How many new laptops, tablets, etc don't have a built-in camera and microphone? How many new cars don't have at least a built-in microphone ("for bluetooth") and some form of ability to phone home?
If the dev considers collaborating well with others, taking ownership and responsibility of their own talents and shortcomings, being accountable to their team mates. If a dev considers such things to be akin to "treated like a child", perhaps the dev is still a child.
The fact is a lot of developers got into software because they could retreat into their own cave and not have to grow up. Not have to learn to work and play well with others.
Waterfall et al are all about micromanaging a schoolyard full of undisciplined developers. Agile is for adults, it requires a strong sense of personal responsibility that frankly a lot of devs just don't have.
--
The fact is Agile is the polar opposite of micromanaging. And that is why a lot of devs don't like, they can't stand the responsibility.
Why are documentation, training, qa, etc considered "downstream"?
You might hear the terms "scrummerfall" or "waterscrum" to describe your example, all boiling down to trying to wedge Scrum/Agile into a familiar existing process (typically some flavor of waterfall). It's an anti-pattern, a red flag. You're right, it won't work. But it's worse then that because it adopts the worst of everything and the best of nothing...a total disaster of a process.
You need to rethink the entire SDLC, break away from the idea that these are serialized phases. There are ways of doing most all of this in parallel. For example at the start of a sprint QA can be fleshing out the requirements by working out all the what-ifs and edge cases, which (especially given a good test framework) can be quickly transformed into unit tests. They won't pass (little if anything is implemented yet), and that's fine.
By the middle of the sprint the developers should have most of the core functionality complete and will be tackling the backlog of unit tests QA has created, while the QA people are transitioning to ad-hoc testing.
--
Similarly there's a reason why you don't start the sprint by immediately putting the entire sprint backlog into "in progress". You pull off as few as possible, 1 if you can, in priority order. And stick with it until it's Done, before picking up the next. A not-to-subtle reason for this is because for those things that must be serialized (eg, final screenshots for documentation/training), they can get to work earlier.
If your team has 10 items to do in a sprint and has all ten "in progress" at once, the sprint is likely doomed. Along with the above problem of work that must be serialized, you have also greatly increased the risk because now everything must work or likely nothing can be shipped. If however, you got the top 8 done and weren't able to start the last 2...you still have 8 cleanly shippable items and the last 2 can just move to the top of the next sprint. No code needs to be pulled out, no docs rewritten, etc, because those 2 never happened.
And yet the reality is exactly the opposite: Agile methods are by strong people, for strong people. It simply doesn't work with fuckups (be they drone or Rambo).
But you are right, good devs figured out processes that work. And like any good dev, they refined them over time and with insight from others. Eventually distilling the process into a methodology...and they called it Agile.
That's literally where all this came from: Great devs, using skill, experience, and creativity, to come up with the best ways to solve very common problem found in very similar situations. And then field testing and refining those solutions into a science. The fact is projects, people, companies are much more typical then they are unique. They have the same types of people faced with the same types of problems. Only a bad dev would try and reinvent the wheel for each and every situation. A good dev reuses as much as they possibly can, be it tools, patterns, or processes.
-
And there are reasons the scrum is firmly at the same exact time, every single day. A big one is directly addressing your concern about interruption and loss of context. When it's held at a reliable time it's hardly any more of an interruption or loss of context then is the sun rising to start the day.
Yes, this does mean that developers who have become accustom to waking up whenever they feel like it, showing up (or not) at whatever time they like, operating entirely within the vacuum of reality that is the fleeting whims of their own mind and theirs alone. It does mean such developers are not going to take kindly to Agile.
Yet the fact is solid team work is a incredibly huge multiplier, far outweighing even the best "Rambos", and you can't have teamwork with people who don't show up. So I'll take a good developer who has good team work skills over a great developer with no team work skills any day.
Agile isn't a solution to the common problem of ignorant, mediocre management.
Agile empowers good and great people to perform at their best, consistently, even establishing a new benchmark for best. Agile processes are systems by strong people for strong people.
What Agile does not do, is work well with mediocre and/or defective people. It can't solve staffing problems, no matter where in the business food chain they are found (most often at the top).
1) No one is asking you to comment on other people's work, or asking them to comment on yours. Again, that's not what the scrum is for.
2) The fact that you're swimlaned so strongly, with such specialized knowledge, strongly brings into question your assertion that you are keeping up on what your team mates are working on. It suggests you're a collection of Rambos, not a team.
The notion of a team implies teamwork. Occasionally consulting each other is no more team work then occasionally consulting stackoverflow.
And that's why they're now arming the police with the same advanced military gear the army uses. Unlike the army, America's cops have a long and disgustingly proud history of killing their own civilians without remorse.
Yet Scrum doesn't allow for micromanagers, and the daily scrum doesn't allow for any manager to speak or ask questions. At all. No really.
The scrum is for the team. If you just have a collection of developers and not a team, the scrum is pointless. If however, you actually are a team, the scrum is invaluable.
Simple: Keep the team in sync, keep the sprint in perspective, keep the project on target. And less talked about, to keep developers honest.
The fact is a lot can and does happen in just a couple days. If you let your developers all run off to their own corners for days at a time your entire project will be spaghetti almost as fast. This is doubly so for "Rambo" developers and drones, the ones most hostile to daily scrums.
5-15 minutes out of an 8 hour day is hardly a burden if you're actually doing work, and it really should be that quick. The fact is however, often when a developer knows the boss isn't going to talk to them for three days they will play WoW for two days and jam code together for 4. You can get all offended, but it happens...a lot.
It's much harder to goof off for a day or three when you're forced to stand up in front of your entire team and actually profess to their faces what you have (or haven't) gotten done. To commit to actually getting something done that day. The threat of embarrassment alone is enough to keep most from slipping and goofing off. Pride of self and pride of team is a large factor in the large productivity boosts good Agile settings have been able to achieve.
Again, Rambo developers who like to work on their Call of Duty skillz for 4 days, cram a bunch of crap out on the 5th, and pat themselves on the back as if they're some kind of coding god, just aren't a good fit for Agile. They also aren't half the coder they think they are and aren't worth half the salary their company is paying them. And companies are starting to figure that out.
Agile doesn't let you hide....that's the real reason most are hostile to it.
If you truly couldn't care less about what your team is doing, then they aren't your team and/or you're not a team player. You're either a Rambo or a drone, neither of which is a good fit for an Agile team.
And that's fine. Frankly a lot of software developers aren't a good fit for Agile. Many got into software specifically because they prefer to work isolated in a cave and tune everyone else out. They like working remote from a coffee shop or whatever.
That however, doesn't make Agile a bad choice for the project or business, it just makes those developers a bad choice. The fact is there are a great deal of developers in the world who are at least as good as you are plus they are team players, they are able to leverage the power of a good team to boost their own performance and their coworkers to new heights they couldn't achieve on their own.
So you're free to keep pretending you're Rambo, the greatest thing to happen to software since cc. Just as businesses are free to hire someone else who'll ultimately offer them far more value directly and indirectly then you ever will.
Yet, in practice there's a huge difference:
In a waterfall scenario the customer most often doesn't see anything tangible until way late in the process. Only then are they able to see the project is off course...and by that time it's way, way off course requiring a large, expensive change.
In an agile scenario the customer sees everything early and often, allowing them to keep the project on course with minor adjustments along the way. Any changes they make late in the process are almost certainly to be a fraction of the size of changes they'd have required late in the cycle of a waterfall project.
Forcing most decisions to the front of the process only ensures that they are either wrong or take so long to make that they are no longer relevant by the time the product can be delivered. How wrong and how irrelevant is proportional to how much, how strict, and how early in the process you mandate decisions be made. This is why waterfall most frequently falls into the trap of delivering, "Exactly what they asked for, but not at all what they want/need".
Agile isn't about not making decisions early. Completely the opposite: Agile is about providing the knowledge required as early as possible to make good decisions. Decisions (aka "changes") are made as early as it is possible to correctly make them...and correct from mistakes as early by discovering them sooner.
By contrast waterfall forces most decisions to be made blindly, all but ensuring they will be very wrong, and only discovered after its much, much too late to do anything about it.
Today, sure. But tomorrow?
The current "zip gun" design is simply a proof of concept, proving that you can in fact CTRL+P a working, untraceable, undetectable firearm.
It's not dissimilar to the 3d printed large capacity magazines created before it. Although they're already much more practical: A 30 round clip that's cheap/easy enough to simply be thrown away after 1 use doesn't need to reliably fire more then 30 rounds to be fully effective.
The point however, is that it's a zip-gun today...it's a fully working AR-15 or Glock 17 tomorrow, or even a full on mini-gun, or printed caseless ammo. And "tomorrow" isn't a euphemism for "some day far in the future, maybe, but probably not". No, "tomorrow" really is tomorrow. Between advancements in 3D printer tech, advancements in materials, advancements in software, and a whole bunch of people suddenly becoming interested in and buying their own 3D printers...we'll be far, far past "zip-gun" this time next year.
Wake the fuck up. This really does change everything. This bell cannot be unrung. No matter where you sit politically on issues of guns, this is the new reality and any regulations you care to write can't pretend reality is something else if you want them to have any real effect.
Want to ban 30 round clips so bad guys can't fire so many rounds at once as they're marching through an elementrary school? Or ban assault weapons? Or ban silencers? Or require background checks?
Noble intentions, but how's that going to be effective when 3D printers are as common place and easy to use as ink jet photo printers are today?
It's not rocket science, but it's not obvious either. Your chart is frankly insane. Who in the world is going to remember any of that when they're out at a bar?!
"1 standard drink" = 1 shot = 1.5oz of ~80 proof. Find me a bar anywhere in the world that pours only 1.5oz of alcohol into any drink.
There simply is no such thing as "1 standard drink", anywhere in the world. It's a completely invalid unit of measure. It's not even the average drink size: Its official size is significantly smaller then any drink served anywhere.
Completely, totally, invalid and meaningless.
The average women in America is 156 pounds, the average man 196. http://www.huffingtonpost.com/2012/11/26/ideal-weight-americans-weigh-pounds_n_2193385.html
Are there any women left in America under 120lbs? Or men under 160lbs?
Drink limit charts and such that top out before you even reach the lowest rung of real Americans only confuse people. How many drinks can the average 156lbs women have before reaching 0.05%? And the average 196lbs man? What about the above average (and sadly very, very common) 200+lbs women, 300lbs man? Do you double the recommendations...or do you see that 1 drink is the difference between 120 and 160...so "logically" it's 1 more drink for each 40lbs above the 120lbs floor... So a 300lbs man should be able to drink...5 or 6? A 200 lbs woman should be able to handle 3?
Never mind that what passes for "1 drink" is like the "1 serving" on nutritional info. A typically real drink is easily equivalent to 2-3 "recommended" drinks.
Add the mythical weight specs to the mythical drink sizes and it's little wonder why people are stumbling out of bars thinking they can drive. We told them they could!
I've been to a few rallies. The nutters at the rallies make the online folks look quite reasonable by comparison.
The fact is the Tea Party is nothing more then a front group for a few (very few) billionaires. It was never grass roots, it was never a "movement". It's nothing but a few rich bastards whipping nutters into a frenzy, rattling the screws even looser in the process.
3D printers haven't costs "tens of thousands of dollars" for quite some time: http://store.makerbot.com/3d-printers.html And they aren't hard to use, especially if you're printing someone else's downloaded design.
You're missing the fact the person wanting the gun doesn't need to be the one with the printer. Some gang land arms dealer, who currently sells stolen ("untracable") guns, will be printing untracable guns on demand out of the the trunk of a Pontiac.
Considering the already cheap price of 3D printers and the fact they can print copies of themselves, you're never going to dent criminal use of 3D printing. You're not unringing that bell.
Clearly you're following a different Tea Party then I do.
I'm tuned into most of the major Tea Party social networks and the message to overthrow the US Government via armed rebellion is very thinly veiled if it's veiled at all. The supporters sure get the message loud and clear, posting endless comments about it.
They really do believe in an armed overthrow of the US Government. By "take their country back" they really do mean with lethal force. They aren't joking around, they're deadly serious. They really do want to start a 2nd US Civil War.
DRM (in particular always-online DRM) is absolutely essential in combating hackers/exploiters/cheaters/griefers.
Cheaters will always find new cheats. But if you paid $70 for a game and know you'll basically throw that money away (and/or get your entire Steam or whatever account banned from a lot of other games as well), you'll be far less likely to cheat given that each time you're banned you'll have to shell out another $70 to cheat again.
Always-On DRM also combats pirating games, as well as combats hackers in multiplayer games (a huge win for gamers, or can be).
So long as it's largely out of sight and out of mind (such as Steam's), always-on DRM is very much here to stay. It solves too many otherwise impossible problems and introduces practically no legitimate issues (when done well).
Personally I'm much more in a huff over the move away from community modding and towards DLC. $15 for DLC that effectively just adds two or three maps? When all is said and done a game like MW3 ends up costing $150 rather then just $70, for a tiny fraction of the content a mod-friendly game like Counter-Strike offered (it itself, being a community mod of Half-Life).
You're assuming everyone, or even most people, sell their games. You're also ignoring the lost sales of new games as some people opt to buy used copies.
The only ones I've honestly known that sell their games are kids. Kids who only can get mom and dad to buy them two or three games a year. There's much more money in the 20s, 30s adults with their own disposable income...a group that's far less likely to care about the hassle of selling their games and/or enjoy keeping a collection. At the very least they're going to hang on to a game far longer then a month which drastically reduces its resale value.
So while there will be some that are accustom to the buy(day one)/play(through quick)/sell(fast) model and will be impacted by your math, most of those losses will be made up by once-used game purchasers now buying games new.