Walk them through the Monty Hall Problem (https://en.wikipedia.org/wiki/Monty_Hall_problem) - they won't believe the solution. Then make them write code to simulate the problem and tally the probability seen empirically. Should be a very modest amount of code but pretty fun for them.
It's not like I lost sight of the non-prescriptive nature of Scrum regarding the technical details. It's more that all I could see was this massive risk the Scrum imposed on the team that had to be dealt with *somehow*. This risk was never really discussed in the book and, in the end, I think my point is that if you fail to address the risks that the unspecified parts of the process impose, you'd be well on your way to a death march. I felt the book could not be recommended given that it failed to address this risk.
I read Death March a while back and liked it quite a lot but have a couple of other books I want to review here first ("Modern C++ Design" and "The Mythical Man-Month").
BTW, my rating was supposed to be 0 out of 1, not 0 out of 10:)
It's not exactly controversial to take this stand. The biggest argument against these initiatives that I can think of is that I don't believe that methods of delivering complex systems at a precisly characterized state of high quality are actually *known*. We're not really that far along as an engineering discipline.
So the writers of these virii certainly are doing a bad thing and certainly are aware of this, but it seems to me that Windows/Outlook/Office ship with a big red button and endless admonitions not to push it. Of the two, the button maker and the button pusher, I know who I find fault with most, but I suspect that the media and most observers are becoming accustomed to these ridiculous risk exposures as somehow inherent in computing and thus tend not to blame the button maker. Think also that this effect has something to do with why these problems never seem to actually get *fixed*.
I think of these devices as performance enhancing technology. We hate these in sports precisely because they violate the point of sports - human performance. They ought not to be hated in the arts, though, because the point of art is nothing like that - art is for art's sake and should be judged on its own merits. Consider - instruments of all kinds can be thought of as methods for people to make sounds they would otherwise be incapable of making. Also, I suspect we reverve our revulsion with these techniques for only a subset of their use in music. When Laurie Anderson uses that "make her sound like a guy" thing, no one objects. Another example would be that transexual guy who did the music for A Clockwork Orange. No one would complain over their use of these kinds of technologies because we understand that it's the art that matters in those cases, not the way it was made. A long while back I read an interview with William Burroughs where he was asked to comment on the then recent publication of computer-generated poetry. He said he liked some of it and some of it left him cold. The interviewer asked if he had any reservations, given that it was a program that had written the work. His response was more or less that he'd been asked to comment on the art, not the artist. At the end of the day, the most likely use of this stuff will be to help shitty singers make shitty music, yes, but there will always be shitty music. But I bet you somewhere out there, Lou Reed's bitching about why they didn't have this thirty years ago:)
Smalltalk has no compile-time type-checking, yet is considered THE most OO language by many.
IOW, type-checking and OO are perhaps orthogonal concepts.
I was talking about the distinction between procedural languages and assembly. I wasn't referring to OO languages at all. My essential point is that assembly guys could make similar arguments against procedural constraints that you are regarding OO.
Man, I'll eat my freaking paycheck if the procedural paradigm is still in vogue in 15 years. Type-checking - pah, that's for children! Assembler was good enough for my grand-pappy and by gum it's good enough for me.
PS I only said that because my grand-pappy was in the room - just give me a keyboard with a one and a zero and I'll do it myself! That's the way real men write crappy code!
Slashdot Mirror
Walk them through the Monty Hall Problem (https://en.wikipedia.org/wiki/Monty_Hall_problem) - they won't believe the solution. Then make them write code to simulate the problem and tally the probability seen empirically. Should be a very modest amount of code but pretty fun for them.
FWIW, you are all confusing the CMM and the CMMI.
E
It's not like I lost sight of the non-prescriptive nature of Scrum regarding the technical details. It's more that all I could see was this massive risk the Scrum imposed on the team that had to be dealt with *somehow*. This risk was never really discussed in the book and, in the end, I think my point is that if you fail to address the risks that the unspecified parts of the process impose, you'd be well on your way to a death march. I felt the book could not be recommended given that it failed to address this risk.
:)
I read Death March a while back and liked it quite a lot but have a couple of other books I want to review here first ("Modern C++ Design" and "The Mythical Man-Month").
BTW, my rating was supposed to be 0 out of 1, not 0 out of 10
Should be 0 out of 1, not 1 - my mistake.
:)
I take the guess-work out of the buy/no buy decision by giving boolean-valued reviews
That can't be right ...
It's not exactly controversial to take this stand. The biggest argument against these initiatives that I can think of is that I don't believe that methods of delivering complex systems at a precisly characterized state of high quality are actually *known*. We're not really that far along as an engineering discipline.
So the writers of these virii certainly are doing a bad thing and certainly are aware of this, but it seems to me that Windows/Outlook/Office ship with a big red button and endless admonitions not to push it. Of the two, the button maker and the button pusher, I know who I find fault with most, but I suspect that the media and most observers are becoming accustomed to these ridiculous risk exposures as somehow inherent in computing and thus tend not to blame the button maker. Think also that this effect has something to do with why these problems never seem to actually get *fixed*.
I think of these devices as performance enhancing technology. We hate these in sports precisely because they violate the point of sports - human performance. They ought not to be hated in the arts, though, because the point of art is nothing like that - art is for art's sake and should be judged on its own merits. Consider - instruments of all kinds can be thought of as methods for people to make sounds they would otherwise be incapable of making. Also, I suspect we reverve our revulsion with these techniques for only a subset of their use in music. When Laurie Anderson uses that "make her sound like a guy" thing, no one objects. Another example would be that transexual guy who did the music for A Clockwork Orange. No one would complain over their use of these kinds of technologies because we understand that it's the art that matters in those cases, not the way it was made. A long while back I read an interview with William Burroughs where he was asked to comment on the then recent publication of computer-generated poetry. He said he liked some of it and some of it left him cold. The interviewer asked if he had any reservations, given that it was a program that had written the work. His response was more or less that he'd been asked to comment on the art, not the artist. At the end of the day, the most likely use of this stuff will be to help shitty singers make shitty music, yes, but there will always be shitty music. But I bet you somewhere out there, Lou Reed's bitching about why they didn't have this thirty years ago :)
I was talking about the distinction between procedural languages and assembly. I wasn't referring to OO languages at all. My essential point is that assembly guys could make similar arguments against procedural constraints that you are regarding OO.
PS I only said that because my grand-pappy was in the room - just give me a keyboard with a one and a zero and I'll do it myself! That's the way real men write crappy code!