21–30 of 46 posts
This will be difficult to do in text (imagine a triangle): Quality Time Cost Right, which one is more important? and more importantly who gets to decide which one is more important?
You can have all three. Prioritizing quality from the start, by doing design reviews, pair programming, tdd and so on, will actually reduce time needed to deliver fully functional software, and therefore lower overall cost.
In practice? Pick a spot inside the triangle.
Earlier quoted context omitted.
Yep, managers seem to think the triangle can be overcome with enough money/prowess/brute force.
Well, if they're willing to invest money, then they've chosen, no? Cost is not important, but timeliness and quality are.
"We value reliable software", is nice, but everyone values that. But if you said "We value reliable software over meeting deadlines", then you'd actually have said something. The power of the Agile Manifesto was that it clearly identified tradeoffs they were willing to make.
This reminds me of a Jamie Zawinski quote from the book "Coders at Work":
> [...] Are you trying to write good software or are you
> trying to be done by next week? You can't do both. One
> of the jokes we made at Netscape a lot was, "We're
> absolutely 100 percent committed to quality. We're going
> to ship the highest-quality product we can on March 31st."When in 2009 I was calling it "Fragile," not "Agile," people were laughing at me as yet again I wasn't politically correct!
Back in 2014 I wrote a blog post "Antifragile Software Ecosystems" that discusses how IMO antifragility relates to how software is developed.
https://opkode.com/blog/2014/01/14/antifragile-software-ecos...
Earlier quoted context omitted.
They try to prioritize their principles, but they are vague. Let's see: > Our highest priority is to satisfy the customer by building a non-linear, proactive, and self adaptive system Okay, firstly, what is that? And secondly, does it serve the customer if those are not the customer's requirements? What if I don't want a "self adaptive" system, whatever that is? It could be bad: self-adaptive software keeps some glob…
> what is that? A collection of popular buzz-words in contemporary software engineering research. > And secondly, does it serve the customer if those are not the customer's requirements? These are never any customer's requirements. Not a sane customer, at least. Instead, they are (conjectured, probably correctly, to be) generalizations of sufficiently many customers' requirements. But you're correct -- most customers…
The Black Swan was also by Taleb and probably the most influential finance book of the last 20 years, plus a great read for anybody thinking in 'systems'. It'd give the idea the benefit of the doubt. Sometimes words have no meaning, sometimes it takes some work.
When in 2009 I was calling it "Fragile," not "Agile," people were laughing at me as yet again I wasn't politically correct!
I don't think it's mainly about agile. There is plenty of good examples of fragile OSS out there that has nothing to do with agile. Entire npm ecosystem is very good example.
Earlier quoted context omitted.
> what is that? A collection of popular buzz-words in contemporary software engineering research. > And secondly, does it serve the customer if those are not the customer's requirements? These are never any customer's requirements. Not a sane customer, at least. Instead, they are (conjectured, probably correctly, to be) generalizations of sufficiently many customers' requirements. But you're correct -- most customers…
Or you could read the book. I haven't (summer reading list, again). But it's got a 20-page bibliography, and appendices with all sorts of greek letters that define, well, a lot. I think. The Black Swan was also by Taleb and probably the most influential finance book of the last 20 years, plus a great read for anybody thinking in 'systems'. It'd give the idea the benefit of the doubt. Sometimes words have no meaning,…
Reading Taleb's book to answer that question is probably a lot like trying to extract evolved dogma out of a religious text because each of those words has taken on a life and meaning of their own in SE literature. You can probably eventually get close, but you're better off just reading a few SE papers on those topics and inferring the authors' intended meaning.
As with any manifesto, words, interpretation, and practice are where they fail. I've been through the Agile/Scrum classes, yeah, great. Does management buy in, despite professing such? Yeah, not so great. Unfortunately, for me, whenever I see the word "manifesto" in relation to computers, this is the one I immediately remember... http://phrack.org/issues/7/3.html
And this is the one I remember instead: http://programming-motherfucker.com
Earlier quoted context omitted.
I don't think it's mainly about agile. There is plenty of good examples of fragile OSS out there that has nothing to do with agile. Entire npm ecosystem is very good example.
It's not only about Agile, but incremental development is always detrimental especially for complex projects. Also, most companies apply some ghetto version of Scrum, most don't even know what SOS (Scum of Scrums) is, pick and treat the Scrum Master incorrectly, don't even do Planning Poker, don't use Epics at all, don't define stories right, don't use burndown charts at all, etc. In most cases, I see Scrum as an eye…
I really have to dispute that.
First, it's not really clear what you mean by "detrimental" - is that to software quality, or development schedule, or suitability? Or all of them, or others? Agile is very clear about the trade-offs - working products being more important than documentation for example, or responding to change over following plans.
Second, I don't think it's true. I've directly observed, in multiple organisations, that agile development is perfectly capable of delivering good systems on-budget and on-schedule. If anything, it's especially good for complex systems, which are those most likely to require flexibility and have hidden requirements.
I also dispute the idea that "ghetto Scrum" is invalid. Development processes should be tailored to the requirements of the product, organisation and team. Not every team needs epics or planning poker or scrum of scrums, and it's totally valid to take some of the ideas of scrum and apply them to your own development process without having to buy the whole thing.
I consistently see agile development hand waved away with this argument that it doesn't work because there are companies which do it badly, and it's baffling to me.