You know Bin Laden was trained by the CIA, don't you? Terrorists are a cheap way to fight your enemy. Russia in this case. But you do end up breeding more terrorists.
The NSA only participates in activities governed by Congress, President and the Courts. If you don't like the NSA, then stop voting for the Congress (R congress, D Senate), the President (D) and those that appointed the Supreme Court.
Congress is already out of the picture if the NSA gets away with lying to them.
But if an NSA actually wants to protect America from very real threats, he gets his life destroyed. And NSA job works best if you have no morals or conscience.
And if you had read the linked articles, you would have seen the prior occurrence with wikileaks. Having both Visa & Mastercard not accept either the wikileaks donations or VPN payments at the same time seams suspicious.
"Seems suspicious"? It was already obvious that they take orders from Washington, in exchange for diplomatic support for their expansion into Russia and other markets.
It was already obvious that Visa and Mastercard are not neutral payment providers, and therefore not reliable as international payment infrastructure.
This just underscores even more that we need better payment infrastructure. The world can't afford to be dependent on these two companies for its economic traffic.
If this was done to Air Force One, there would be outrage and calls for war.
Of course. But it wasn't Air Force One, it was merely the plane of the president of some unimportant country that's not the US. So who cares, right? Only the US really matters. Only the people in charge of the US really matter, I mean. If there's one thing abundantly clear now, it's that.
Something that never fails to terrify me is when I have to deploy an existing site to production for the first time. People are already using it, and if I messed anything up (introduce a bug, built the war incorrectly, forgot to update some production property that I did update for test, deploy in the wrong way somehow, or even just deploy at the wrong time), people will not be able to use the site anymore because of me.
I love automated deploy scripts for exactly this reason. And having access only to test, while deploying to production is someone else's responsibility.
Their core market is advertising. They need information to know what kind of advertisements are most relevant for you.
Basically they want two things: * More information on what people are looking for or interested in, * More people using internet, looking for stuff they're interested in.
So their investment in internet infrastructure (fiber, balloons) is more making more people use the internet more. Android same thing. Everything else is for figuring out what you're interested in so they can show you advertisements you're likely to click on.
I have no problem with homosexuals, but I do wish they'd shut up from time to time (well, I'm sure other Slashdotters could say the same about me too:) )
I suspect they might feel the same way about heterosexuals.
Seriously, look at all the heterosexual references in media. I think gays have more cause to complain.
I believe we're currently producing enough food for 10 billion people. (Of course we're not actually feeding it to people, we're feeding it to cattle.) With the right choices, food and water shouldn't be the problem here (though making the right choices in itself probably would be). As for other resources, it depends on the resources everybody needs. If all 11 billion of them want big SUVs and lots of steak, then it's not going to work.
What's the big deal here? Obviously they want whatever is discussed in that meeting to remain confidential, at least for some time.
If they're saying things they don't want people to know about, then maybe they should consider not saying those things at all. That's what Eric Schmidt would say about that.
Google is one of the prime proponents of the idea that privacy is utterly dead, but for their own shareholder meeting it's suddenly relevant again? They need to make up their mind, because now they're undermining their own main argument.
That's why it doesn't just come out at the end. We show what we've got at the end of every sprint. If it sucks eggs, we can change it. Without Agile, we'd discover this much later. And the earlier you discover this stuff, the cheaper it is to change it.
This assertion is a fallacy, Example: you create the ability to register a user, then edit that user, then assign it to a group, etc. The requirements come out over 6 iterations and are worked in across roughly 10. Yes, it is demo'd every time and accepted. Then the business tweaks the back end service requirements a small bit, causing some major changes in the front end, after which they look at it and go - wow, wouldn't it be cool if we combined this suite of functionality into a single functional piece? And many iterations later, that newly envisioned piece, that requires a whole new backend suite of services, is still in flux. Fortunately I'm not responsible for that, only that it and other issues have moved the delivery date out by a factor of 4.
I don't know why you'd want to do it like that, but if you do, then I'm really interested in hearing how Waterfall or anything else would handle this better.
It should put more power in the hands on developers, not less. If it's used as an excuse for micromanagement, it's definitely not Agile.
Nice try, but the reality is quite different. Managers love agile because of daily standup meetings. That is the height of micromanagement (constant status reports) and puts pressure on the devs to accomplish something everyday.
There's nothing wrong with accomplishing something every day. It's what you're paid for, isn't it? There's also nothing wrong with daily status updates. But the important thing is that the standup meeting is by and for the development team. Managers and other outsiders aren't required, though they are welcome.
If you feel that way, then maybe software development isn't for you.
You're wrong. I'm well-suited to software development because I care about the end result of the entire team, rather than just the bit that's been assigned to me. I'm well-suited to software development because I can work in a team. Teams are unavoidable in any major software project.
I don't see it much differently that writing a book (in terms of the actual working environment). Presumably book authors do it because they love to write. The fact that it's a solitary job is irrelevant. I write code because I love to write code. I don't need my work environment to be a place for friends to socialize.
So you write your own code on your own. That's perfectly fine of course. It can be a fun hobby, great for learning to code, you may do small projects on your own, maybe you have a wildly successful app. But large software projects are unavoidably a team effort. They're not like writing your own private book.
If they're that important, then surely their issue deserves to be properly spec'ed, doesn't it? I can't read his mind, even if he is an Executive. I'm not going to guess at what an executive might mean. I need to know. Otherwise I'll probably do it wrong, and I'm sure that's not what the Executive wants, is it?
You seem to be operating on the naïve assumption that the complainer cares about getting it fixed, rather than grandstanding in order to look important or just being a dick for the sake of it.
No, I'm being practical. If he honestly wants to get it fixed, he wants to provide me with the means to fix it. If he just wants to be a dick, he can do that without any action on my part.
With Agile, X is 100%, and the cost tends to be fairly high because there is no design and no effort put to possible future use cases or changes up front.
Of course there is design and effort to get as much stuff as possible sorted out up front. But it doesn't have to be perfect, and it can adapt when something is missing, incomplete or wrong.
Making sure the design anticipates every possible future need costs a lot of money, and most of that will be wasted. It doesn't have to be perfect at the first try, and you don't have to spend a ton of time and money to refine it until it's perfect before you can start programming. Do what you can up front, but there's still room to adapt later on (as long as you don't postpone everything).
"We don't accept issues that don't meet our standards" - I am skeptical of this being as simple as it is stated here. Every environment I have worked in has resisted this heavily, especially when the issues being created are filed by people with "Executive" in their job title. Usually it's "This is broken go fix it" and if the person filing the issue has enough juice, nobody will dare go back to them for more information, they're far too important for that.
If they're that important, then surely their issue deserves to be properly spec'ed, doesn't it? I can't read his mind, even if he is an Executive. I'm not going to guess at what an executive might mean. I need to know. Otherwise I'll probably do it wrong, and I'm sure that's not what the Executive wants, is it?
I'm very fortunate that it really does work like that here. If we need to make a feature where part of the texts, design or something else is missing or unclear, we send it back, specify exactly what we need before we can put this in a sprint, and they provide it. And if they don't, it doesn't get in the sprint.
We have a "Definition of Ready". Issues that don't meet those standards, cannot be included in a sprint.
We do on rare occasions deviate from our standards of course; we recently included some extra work in a sprint that was already in progress and nearly over, and doing so meant postponing several other issues. We didn't make that sprint, and we made it clear that that was because we had to include extra work at the last minute (as well as several other unexpected problems during that sprint). But that's all part of being Agile.
Some companies are worse than others, but I have yet to be at a company (and I've worked for several Fortune 500 companies) where IT/Engineering were first class citizens, able to require more information to solve a problem.
It's a rare experience for me too, but I'm very glad that that's how it works here. Maybe it's because this is a train company; perhaps those are more engineering-minded. But now that I've experienced it, I'm convinced that this is the only way to work. If management insists on Agile, then this is what they have to do.
"business, admin and others show up at our standups and our sprint demo" - See above, usually people who actually can make decisions won't deign to attend meetings with people who do actual work.
We insist that they do, and keep reminding them that they should. Those who don't, get less input in what gets made. If they complain, we say they should have been there. Not everybody adapts easily to that, but to those who do, we show gratitude and give them results.
It doesn't always have to be the client himself, but he does need to be represented in the process. This can be done by a business analyst, as long as he knows exactly what the client needs. And when he doesn't he needs to figure this out pronto. But there needs to be someone available who can make these decisions. Having the programmers decide business requirements is a bad idea. It's not their job.
The problem is that customers are not nearly as available as people would like. Either they're located offsite (and won't relocate to be with you or allocate space for you to be with them), or they're short of time because of their other commitments, or they the kind of people who hate being shown works-in-progress.
That's definitely a problem, and it needs to be solved. If you can't have a Product Owner who's available to the team, you can't do Scrum. Product Owner is a vital job. It doesn't have to be the customer, though. It could be an analyst who knows exactly what the customer needs. That is absolutely fine, as long as the analyst keeps in touch with the customer's wants and needs.
Also, customers aren't (necessarily) users or vice versa. That's a major piece of tension right there.
Code reviews are only part of it. If that's truly all your involvement with your co-workers, that's sad.
No, it means I'm spending most of my work time actually working on the things assigned to me, i.e., what you're paying me for. It makes me maximally productive and either on-time or ahead of schedule.
Until your code runs into a conflict with someone else's code because of a lack of communication. Communication is vital if you want a productive team. Your attitude is fine if you work alone, but not in a team.
You can get the same result with a daily email, but you usually won't. Daily emails usually don't get the same results and involvement.
If you've already drank the Agile Kool-Aid, how do you actually know you won't get the same results? And if you don't get them, why not figure out how to solve that problem (while still using e-mail).
I have used daily emails before I experienced real Scrum. I wanted it to work, but it didn't work remotely as well as a daily standup.
Slashdot Mirror
Of course not, but that doesn't change the underlying fact. Live by the sword, die by the sword.
We are a nation of laws
Used to be. What use are those laws when the NSA simply breaks them? What use is congressional oversight when the NSA simply lies to them?
Terrorism didn't start on 9/11.
You know Bin Laden was trained by the CIA, don't you? Terrorists are a cheap way to fight your enemy. Russia in this case. But you do end up breeding more terrorists.
The NSA only participates in activities governed by Congress, President and the Courts. If you don't like the NSA, then stop voting for the Congress (R congress, D Senate), the President (D) and those that appointed the Supreme Court.
Congress is already out of the picture if the NSA gets away with lying to them.
But if an NSA actually wants to protect America from very real threats, he gets his life destroyed. And NSA job works best if you have no morals or conscience.
And if you had read the linked articles, you would have seen the prior occurrence with wikileaks. Having both Visa & Mastercard not accept either the wikileaks donations or VPN payments at the same time seams suspicious.
"Seems suspicious"? It was already obvious that they take orders from Washington, in exchange for diplomatic support for their expansion into Russia and other markets.
It was already obvious that Visa and Mastercard are not neutral payment providers, and therefore not reliable as international payment infrastructure.
This just underscores even more that we need better payment infrastructure. The world can't afford to be dependent on these two companies for its economic traffic.
If this was done to Air Force One, there would be outrage and calls for war.
Of course. But it wasn't Air Force One, it was merely the plane of the president of some unimportant country that's not the US. So who cares, right? Only the US really matters. Only the people in charge of the US really matter, I mean. If there's one thing abundantly clear now, it's that.
Something that never fails to terrify me is when I have to deploy an existing site to production for the first time. People are already using it, and if I messed anything up (introduce a bug, built the war incorrectly, forgot to update some production property that I did update for test, deploy in the wrong way somehow, or even just deploy at the wrong time), people will not be able to use the site anymore because of me.
I love automated deploy scripts for exactly this reason. And having access only to test, while deploying to production is someone else's responsibility.
I'd rather they actually put a stop to it, but I guess we have to be happy that at least some senators are willing to address lies by the government.
Their core market is advertising. They need information to know what kind of advertisements are most relevant for you.
Basically they want two things:
* More information on what people are looking for or interested in,
* More people using internet, looking for stuff they're interested in.
So their investment in internet infrastructure (fiber, balloons) is more making more people use the internet more. Android same thing. Everything else is for figuring out what you're interested in so they can show you advertisements you're likely to click on.
I have no problem with homosexuals, but I do wish they'd shut up from time to time (well, I'm sure other Slashdotters could say the same about me too :) )
I suspect they might feel the same way about heterosexuals.
Seriously, look at all the heterosexual references in media. I think gays have more cause to complain.
I believe we're currently producing enough food for 10 billion people. (Of course we're not actually feeding it to people, we're feeding it to cattle.) With the right choices, food and water shouldn't be the problem here (though making the right choices in itself probably would be). As for other resources, it depends on the resources everybody needs. If all 11 billion of them want big SUVs and lots of steak, then it's not going to work.
Who, or what, isn't evil?
Ecosystems that sustain life aren't evil, so it makes sense to prioritize them.
What's the big deal here? Obviously they want whatever is discussed in that meeting to remain confidential, at least for some time.
If they're saying things they don't want people to know about, then maybe they should consider not saying those things at all. That's what Eric Schmidt would say about that.
Google is one of the prime proponents of the idea that privacy is utterly dead, but for their own shareholder meeting it's suddenly relevant again? They need to make up their mind, because now they're undermining their own main argument.
That's why it doesn't just come out at the end. We show what we've got at the end of every sprint. If it sucks eggs, we can change it. Without Agile, we'd discover this much later. And the earlier you discover this stuff, the cheaper it is to change it.
This assertion is a fallacy, Example: you create the ability to register a user, then edit that user, then assign it to a group, etc. The requirements come out over 6 iterations and are worked in across roughly 10. Yes, it is demo'd every time and accepted. Then the business tweaks the back end service requirements a small bit, causing some major changes in the front end, after which they look at it and go - wow, wouldn't it be cool if we combined this suite of functionality into a single functional piece? And many iterations later, that newly envisioned piece, that requires a whole new backend suite of services, is still in flux. Fortunately I'm not responsible for that, only that it and other issues have moved the delivery date out by a factor of 4.
I don't know why you'd want to do it like that, but if you do, then I'm really interested in hearing how Waterfall or anything else would handle this better.
It should put more power in the hands on developers, not less. If it's used as an excuse for micromanagement, it's definitely not Agile.
Nice try, but the reality is quite different. Managers love agile because of daily standup meetings. That is the height of micromanagement (constant status reports) and puts pressure on the devs to accomplish something everyday.
There's nothing wrong with accomplishing something every day. It's what you're paid for, isn't it? There's also nothing wrong with daily status updates. But the important thing is that the standup meeting is by and for the development team. Managers and other outsiders aren't required, though they are welcome.
Agile doesn't solve problems. People do. There's your problem right there.
You are entirely correct. Agile is a tool to solve that problem. You still need people to wield that tool properly.
A hammer can be used to make things, but it can also be used to destroy. Even the best hammer won't turn a crappy carpenter into a master craftsman.
If you feel that way, then maybe software development isn't for you.
You're wrong. I'm well-suited to software development because I care about the end result of the entire team, rather than just the bit that's been assigned to me. I'm well-suited to software development because I can work in a team. Teams are unavoidable in any major software project.
I don't see it much differently that writing a book (in terms of the actual working environment). Presumably book authors do it because they love to write. The fact that it's a solitary job is irrelevant. I write code because I love to write code. I don't need my work environment to be a place for friends to socialize.
So you write your own code on your own. That's perfectly fine of course. It can be a fun hobby, great for learning to code, you may do small projects on your own, maybe you have a wildly successful app. But large software projects are unavoidably a team effort. They're not like writing your own private book.
You seem to be operating on the naïve assumption that the complainer cares about getting it fixed, rather than grandstanding in order to look important or just being a dick for the sake of it.
No, I'm being practical. If he honestly wants to get it fixed, he wants to provide me with the means to fix it. If he just wants to be a dick, he can do that without any action on my part.
With Agile, X is 100%, and the cost tends to be fairly high because there is no design and no effort put to possible future use cases or changes up front.
Of course there is design and effort to get as much stuff as possible sorted out up front. But it doesn't have to be perfect, and it can adapt when something is missing, incomplete or wrong.
Making sure the design anticipates every possible future need costs a lot of money, and most of that will be wasted. It doesn't have to be perfect at the first try, and you don't have to spend a ton of time and money to refine it until it's perfect before you can start programming. Do what you can up front, but there's still room to adapt later on (as long as you don't postpone everything).
That should have been worked out during the design phase.
Does that really work? Does your design really pre-empt all communication?
I'd consider that a really impressive feat by your design phase, but it also sounds kinda lonely.
"We don't accept issues that don't meet our standards" - I am skeptical of this being as simple as it is stated here. Every environment I have worked in has resisted this heavily, especially when the issues being created are filed by people with "Executive" in their job title. Usually it's "This is broken go fix it" and if the person filing the issue has enough juice, nobody will dare go back to them for more information, they're far too important for that.
If they're that important, then surely their issue deserves to be properly spec'ed, doesn't it? I can't read his mind, even if he is an Executive. I'm not going to guess at what an executive might mean. I need to know. Otherwise I'll probably do it wrong, and I'm sure that's not what the Executive wants, is it?
I'm very fortunate that it really does work like that here. If we need to make a feature where part of the texts, design or something else is missing or unclear, we send it back, specify exactly what we need before we can put this in a sprint, and they provide it. And if they don't, it doesn't get in the sprint.
We have a "Definition of Ready". Issues that don't meet those standards, cannot be included in a sprint.
We do on rare occasions deviate from our standards of course; we recently included some extra work in a sprint that was already in progress and nearly over, and doing so meant postponing several other issues. We didn't make that sprint, and we made it clear that that was because we had to include extra work at the last minute (as well as several other unexpected problems during that sprint). But that's all part of being Agile.
Some companies are worse than others, but I have yet to be at a company (and I've worked for several Fortune 500 companies) where IT/Engineering were first class citizens, able to require more information to solve a problem.
It's a rare experience for me too, but I'm very glad that that's how it works here. Maybe it's because this is a train company; perhaps those are more engineering-minded. But now that I've experienced it, I'm convinced that this is the only way to work. If management insists on Agile, then this is what they have to do.
"business, admin and others show up at our standups and our sprint demo" - See above, usually people who actually can make decisions won't deign to attend meetings with people who do actual work.
We insist that they do, and keep reminding them that they should. Those who don't, get less input in what gets made. If they complain, we say they should have been there. Not everybody adapts easily to that, but to those who do, we show gratitude and give them results.
It doesn't always have to be the client himself, but he does need to be represented in the process. This can be done by a business analyst, as long as he knows exactly what the client needs. And when he doesn't he needs to figure this out pronto. But there needs to be someone available who can make these decisions. Having the programmers decide business requirements is a bad idea. It's not their job.
The problem is that customers are not nearly as available as people would like. Either they're located offsite (and won't relocate to be with you or allocate space for you to be with them), or they're short of time because of their other commitments, or they the kind of people who hate being shown works-in-progress.
That's definitely a problem, and it needs to be solved. If you can't have a Product Owner who's available to the team, you can't do Scrum. Product Owner is a vital job. It doesn't have to be the customer, though. It could be an analyst who knows exactly what the customer needs. That is absolutely fine, as long as the analyst keeps in touch with the customer's wants and needs.
Also, customers aren't (necessarily) users or vice versa. That's a major piece of tension right there.
That's a problem with every methodology.
No, it means I'm spending most of my work time actually working on the things assigned to me, i.e., what you're paying me for. It makes me maximally productive and either on-time or ahead of schedule.
Until your code runs into a conflict with someone else's code because of a lack of communication. Communication is vital if you want a productive team. Your attitude is fine if you work alone, but not in a team.
If you've already drank the Agile Kool-Aid, how do you actually know you won't get the same results? And if you don't get them, why not figure out how to solve that problem (while still using e-mail).
I have used daily emails before I experienced real Scrum. I wanted it to work, but it didn't work remotely as well as a daily standup.