That would have just been called "getting IT to learn from developers" or something, it doesn't even attempt to describe a new process, system, or role; just purely telling one side to get their heads out of their asses. If that is all it was, no wonder they got ignored by most companies!
It seems painfully obvious to me; if you're suffering under a BOFH already, asking them to increase cooperation is not going to be productive from the development perspective, because the developers see themselves as the purpose of the whole shebang. Of course they're not going to adopt methodologies that require specific software support, that software will never make the list.
That's what real devops is all about though; translating that divide to language acceptable on both sides, and maybe telling the developers what library they're just going to have to decide to like.
In the old days devops was one person because they were simply a sort of translator between the development team and the BOFH, an almost-developer who understands system administration well enough to figure out what technologies are allowed that will meet the needs of the team, and what configuration changes can<->should be made.
Surely Visual Cafe was a crime against humanity, but if they punished them for it they'd probably also have to round up McAfee and he's really popular these days.
Kaspersky also "defends" themselves by claiming it isn't their fault the Russian intelligence services stole access, they claim to just be a crime victim. Problem is, they continue to also cooperate with the Russian government. They're Russian, so of course they have to.
But the net total of that is that they admit to be controlled by the Russian government, they just don't want to lose business over it. Which is understandable, but not a strong argument.;)
It isn't a he-said-she-said, it is a bunch of hand-waving with idiots claiming not to comprehend the known facts.
They certainly don't deny that the NSA's data ended up with the FSB, or that they were the conduit.
It sounds pretty stupid to me; why would slashdot readers be presumed to work as taxi or delivery drivers?
I thought most of the people here did tech work.
Self-driving cars will steal my job never; why would a software-writing AI be given a street-legal automobile as a freakin' case?! I'm thinking the AI that steals my job will fit in a standard 19" form factor server rack.
Yeah, if it is a guarantee that the customer sucks at describing their problems, the problem for the developer isn't the process being used, it is the low quality of the work.
And lets be real; customers who don't know what they want are just making crappy websites, and red or green, rounded corners or a little more rounded, it doesn't fucking matter anyways. That's the kind of shit that benefits, not actual useful features. If you don't know what your useful features are, you don't even have a business plan. Probably no investors. Probably the client can't even afford to pay out the estimated amount of the project, which is why they agreed to a weekly dev model in the first place.
The idea that in "waterfall" the requirements can't change when there are actual reasons for change is just a straw man; a version of "waterfall" that relies on misunderstanding the first edition of the book and adding in a bunch of absolutes that were never implied, simply because that first version of the book didn't include explicit steps for it; they simply presumed that if requirements change, a human takes a look at it and alters things ad-hoc depending on the realities of the situation.
The idea that assessing requirements at the start somehow positions you to be opposed to changes is just vapid bullshit with no logical basis.
When the customer has real requirements and the developer accuses the customer of not describing them well, it is usually just that the developer is an insufferable neckbeard who failed to recognize his responsibility to understand the use case and translate the requirements from business English. Often they even saw their mistake, but put their nose up in the air and intentionally got it wrong in order to try to emphasize through a passive-aggressive attack that the customer is non-technical; often they're so insufferable they don't even understand that their behavior is basically fraudulent.
Nope, that just shows you're an idiot who substitutes attempting to identify teams for thinking.
Your comment was fucking stupid, I don't give a rat's ass which "side" you're on. I said it was shit because it was uninteresting and uninsightful, not because you were wearing the wrong color shirt.
Whinging about mods guarantees you were in the wrong, so you have nowhere to argue from. Welcome to slashdot. As a new kid, please fucking learn that you don't whine about mods.
Your problem was, you were unable to read English words and understand them.
You spent the time to reply, but then you converted my variable into an absolute, and attacked the absolute. Hey cluestick, you're the one who inserted the second "always," it wasn't in what you were responding to. Presumably I used too many words for you to comprehend, which you could simply recognize on your own and ignore.
Your proposed "corollary" isn't even a corollary. A corollary follows from what came before. You're not following from, you're just proposing an alternative.
You have a strange concept of sincerity; it was never any secret or scandal that they were selling books, or that the lessons were related to their consulting business.
Perhaps it is people who are anti-business who presume that sincerity must be about changing the world, who then hear the sincerity in their words and presume they're trying to change the world, instead of just understanding that their sincerity implies that they're making more money by following those principles.
The manifesto was written by a bunch of industry programmers who were vacationing together. It didn't come out of any sort of social movement, or anything like that. That's what I was implying when I asked, rhetorically, "Does it depend on knowing who `they' were?"
If you read the Agile Manifesto it is obvious that there are only two ways to use it; your own take on it, or as a cargo cult.
The truisms stop being true as soon as you take them out of the general context and try to force them into some sort of absolute definitions or processes.
If you start from the manifesto, it would only ever be predicted to be useful if your team was already successful and able to do the things it talks about without turning them into rigid policies or rules. And in that case, it is very useful ideas to think about.
It also might be uniquely suitable for consultants who bill hourly and mostly work on things like websites where the technical work is very very light, the client has a fuzzy idea of what they want, and the deliverable is mostly aesthetics. Other types of work the client might need to know when it will be done and how much it will cost, and they potentially might even already have a well-thought-out set of requirements that are highly technical in nature. In that case, planning before starting work can be highly beneficial; measure twice, cut once.
It is sad how many people claim to understand a bunch of highly-technical computer languages, but then they can't even understand the basics of the English language!
For example, they develop some sort of "pet peeve" about a word they perceive to be incorrect, either in spelling or in its mere existence, and then they repeatedly rant about the word. However, each time they do it they're publishing additional examples of their disfavored word, thereby further establishing that it is a known word that is part of the English language.
Worse, most people who do this can't even explain accurately what a dictionary is! They don't understand it is just a list of words known to the author, along with that author's definition.
If you're doing it and have problems, you're doing it wrong.
Then if you're not doing it, and you tell them you're not doing it, but you don't have problems, they insist you're doing it.
Fuck that.
And news flash, there was no such thing as "old, pure waterfall." "Pure" waterfall is where an idiot reads a book about planning before building, and gets really confused and decides that since the book doesn't talk about mid-stream changes, they must be banned! And waterfall-book-guy, whatever his name was, came out later and reminded people, "it was never anything absolute, it was just a first version of the book" but they were all too busy patting themselves on the head to listen.
If you take the time to capture customer requirements at the start, and you did it poorly, that means you suck at capturing customer requirements! Starting work without even having attempted to do it well doesn't seem designed to address the shortcoming in any way. Would it help to know that not everybody sucks at capturing customer requirements? Or that if you suck at doing it at the start, you'll also suck at doing it by the seat or your pants?
Agile is no better and no worse that any other way of doing business.
BDUF / Waterfall is way worse than Agile.
BDUF is guaranteed to be cheaper and faster if the designer is good enough and has the right environment, and its a bottomless moneypit on the other side because you can build something that doesn't work and the suits won't know they were had until the very end when it doesn't work.
Is your organization trying to do its best, or just trying to keep from landing on its face?
If you see jealously in everything, even in criticism of the complaints of people who have shitty self-chosen jobs, it just prevents you from participating in the conversation.
Slashdot Mirror
That would have just been called "getting IT to learn from developers" or something, it doesn't even attempt to describe a new process, system, or role; just purely telling one side to get their heads out of their asses. If that is all it was, no wonder they got ignored by most companies!
That's complete nonsense and just shows you don't care about the topic enough to learn the public details and get them straight in your head.
It seems painfully obvious to me; if you're suffering under a BOFH already, asking them to increase cooperation is not going to be productive from the development perspective, because the developers see themselves as the purpose of the whole shebang. Of course they're not going to adopt methodologies that require specific software support, that software will never make the list.
That's what real devops is all about though; translating that divide to language acceptable on both sides, and maybe telling the developers what library they're just going to have to decide to like.
In the old days devops was one person because they were simply a sort of translator between the development team and the BOFH, an almost-developer who understands system administration well enough to figure out what technologies are allowed that will meet the needs of the team, and what configuration changes can<->should be made.
Surely Visual Cafe was a crime against humanity, but if they punished them for it they'd probably also have to round up McAfee and he's really popular these days.
Kaspersky also "defends" themselves by claiming it isn't their fault the Russian intelligence services stole access, they claim to just be a crime victim. Problem is, they continue to also cooperate with the Russian government. They're Russian, so of course they have to.
But the net total of that is that they admit to be controlled by the Russian government, they just don't want to lose business over it. Which is understandable, but not a strong argument. ;)
It isn't a he-said-she-said, it is a bunch of hand-waving with idiots claiming not to comprehend the known facts.
They certainly don't deny that the NSA's data ended up with the FSB, or that they were the conduit.
It sounds pretty stupid to me; why would slashdot readers be presumed to work as taxi or delivery drivers?
I thought most of the people here did tech work.
Self-driving cars will steal my job never; why would a software-writing AI be given a street-legal automobile as a freakin' case?! I'm thinking the AI that steals my job will fit in a standard 19" form factor server rack.
Yeah, if it is a guarantee that the customer sucks at describing their problems, the problem for the developer isn't the process being used, it is the low quality of the work.
And lets be real; customers who don't know what they want are just making crappy websites, and red or green, rounded corners or a little more rounded, it doesn't fucking matter anyways. That's the kind of shit that benefits, not actual useful features. If you don't know what your useful features are, you don't even have a business plan. Probably no investors. Probably the client can't even afford to pay out the estimated amount of the project, which is why they agreed to a weekly dev model in the first place.
The idea that in "waterfall" the requirements can't change when there are actual reasons for change is just a straw man; a version of "waterfall" that relies on misunderstanding the first edition of the book and adding in a bunch of absolutes that were never implied, simply because that first version of the book didn't include explicit steps for it; they simply presumed that if requirements change, a human takes a look at it and alters things ad-hoc depending on the realities of the situation.
The idea that assessing requirements at the start somehow positions you to be opposed to changes is just vapid bullshit with no logical basis.
When the customer has real requirements and the developer accuses the customer of not describing them well, it is usually just that the developer is an insufferable neckbeard who failed to recognize his responsibility to understand the use case and translate the requirements from business English. Often they even saw their mistake, but put their nose up in the air and intentionally got it wrong in order to try to emphasize through a passive-aggressive attack that the customer is non-technical; often they're so insufferable they don't even understand that their behavior is basically fraudulent.
What's your point? What are you driving at. I do not see any conclusion on the topic of "Agile" in your post.
Ah, OK. I'll consent to give you the additional lesson that you requested.
Points made in discussion include other types of thing than just conclusions.
You're welcome.
Nope, that just shows you're an idiot who substitutes attempting to identify teams for thinking.
Your comment was fucking stupid, I don't give a rat's ass which "side" you're on. I said it was shit because it was uninteresting and uninsightful, not because you were wearing the wrong color shirt.
Whinging about mods guarantees you were in the wrong, so you have nowhere to argue from. Welcome to slashdot. As a new kid, please fucking learn that you don't whine about mods.
Your problem was, you were unable to read English words and understand them.
You spent the time to reply, but then you converted my variable into an absolute, and attacked the absolute. Hey cluestick, you're the one who inserted the second "always," it wasn't in what you were responding to. Presumably I used too many words for you to comprehend, which you could simply recognize on your own and ignore.
Your proposed "corollary" isn't even a corollary. A corollary follows from what came before. You're not following from, you're just proposing an alternative.
Words, they're what's for dinner!
First you have to define your enemy before he can define himself after all.
That's pretty stupid. I mean, seriously.
You're basically claiming to be a troll, and I can just stop my analysis there.
You have a strange concept of sincerity; it was never any secret or scandal that they were selling books, or that the lessons were related to their consulting business.
Perhaps it is people who are anti-business who presume that sincerity must be about changing the world, who then hear the sincerity in their words and presume they're trying to change the world, instead of just understanding that their sincerity implies that they're making more money by following those principles.
The manifesto was written by a bunch of industry programmers who were vacationing together. It didn't come out of any sort of social movement, or anything like that. That's what I was implying when I asked, rhetorically, "Does it depend on knowing who `they' were?"
True enough, it is the oceans that rise to swallow the islands, islands rarely sink into the oceans.
If you read the Agile Manifesto it is obvious that there are only two ways to use it; your own take on it, or as a cargo cult.
The truisms stop being true as soon as you take them out of the general context and try to force them into some sort of absolute definitions or processes.
If you start from the manifesto, it would only ever be predicted to be useful if your team was already successful and able to do the things it talks about without turning them into rigid policies or rules. And in that case, it is very useful ideas to think about.
It also might be uniquely suitable for consultants who bill hourly and mostly work on things like websites where the technical work is very very light, the client has a fuzzy idea of what they want, and the deliverable is mostly aesthetics. Other types of work the client might need to know when it will be done and how much it will cost, and they potentially might even already have a well-thought-out set of requirements that are highly technical in nature. In that case, planning before starting work can be highly beneficial; measure twice, cut once.
Did they really think they could "change the industry," or sell lots of books and get lots of consulting business?
Does it depend on knowing who "they" were?
It is sad how many people claim to understand a bunch of highly-technical computer languages, but then they can't even understand the basics of the English language!
For example, they develop some sort of "pet peeve" about a word they perceive to be incorrect, either in spelling or in its mere existence, and then they repeatedly rant about the word. However, each time they do it they're publishing additional examples of their disfavored word, thereby further establishing that it is a known word that is part of the English language.
Worse, most people who do this can't even explain accurately what a dictionary is! They don't understand it is just a list of words known to the author, along with that author's definition.
Dude, you should go check IRC logs from 2006. LMFAO!
Don't do things just because someone labelled them Best Practice.
And of course the important corollary; always analyze best practices and follow them except when you've identified a good reason not to.
Lack of analysis will lead to a cargo cult in any direction.
No. What make agile work is accountability.
I agree. Anybody that attempts to adopt development methodologies as a mandate must be held accountable, immediately.
If you're doing it and have problems, you're doing it wrong.
Then if you're not doing it, and you tell them you're not doing it, but you don't have problems, they insist you're doing it.
Fuck that.
And news flash, there was no such thing as "old, pure waterfall." "Pure" waterfall is where an idiot reads a book about planning before building, and gets really confused and decides that since the book doesn't talk about mid-stream changes, they must be banned! And waterfall-book-guy, whatever his name was, came out later and reminded people, "it was never anything absolute, it was just a first version of the book" but they were all too busy patting themselves on the head to listen.
If you take the time to capture customer requirements at the start, and you did it poorly, that means you suck at capturing customer requirements! Starting work without even having attempted to do it well doesn't seem designed to address the shortcoming in any way. Would it help to know that not everybody sucks at capturing customer requirements? Or that if you suck at doing it at the start, you'll also suck at doing it by the seat or your pants?
Quit whining about mods, you posted some lame shit there are lots of reasons people downvote you.
And what have they proposed as an alternative?
Work.
See also: http://programming-motherfucke...
Agile is no better and no worse that any other way of doing business.
BDUF / Waterfall is way worse than Agile.
BDUF is guaranteed to be cheaper and faster if the designer is good enough and has the right environment, and its a bottomless moneypit on the other side because you can build something that doesn't work and the suits won't know they were had until the very end when it doesn't work.
Is your organization trying to do its best, or just trying to keep from landing on its face?
If you see jealously in everything, even in criticism of the complaints of people who have shitty self-chosen jobs, it just prevents you from participating in the conversation.