Taylorism and software ---------------------- I guess I still don't get why Taylor thought separating quality out was a good thing in the first place. Sure "soldier"-ing may happen, but is that a reason to make quality a separate department. Isn't that more of a reason to look straight at the source and work on fixing it? [Pat There's a Dilbert strip where he tries to sell his mom on ISDN, not because he's been transfered to sales, but because at his company, "Everyone is in sales." (His mom turns it down, since she's already got frame relay to the sewing room.) They didn't lay off the whole sales department, they just changed everyone's priorities a little. Along the same line, I don't see how having a QA department takes the job of "quality" away from engineers, or how it "makes the job of the quality department punitive instead of constructive" (133). Clearly, companies with QA departments don't allow engineers to create products with absolutely no quality; no project would ever be completed. Instead, it becomes recognized that quality is everyone's goal, and it is so important that there are some people who's only function is to assure quality. How is that bad for anyone? [Saul] TPS is a success story applying different approach to the production system rather than following the classic Taylorism blindly. However, I was wondering if this kind of approach is always guaranteed to succeed considering different working environment ,people, and work ethics. Since the famous Taylorism is full of shortcomings, I suspect there are many cases TPS approach wouldn~Rt work. Then, what is the most important thing to consider in deciding what kind of approach we can choose in our own situation? [Kyung] Is there a time when Taylorism is a good thing? People don't want to be cogs in a machine, but neither do they want to be adrift at sea. Sometimes it's nice not to have too much responsibility (especially when things aren't going well.) [Soren] The book mentioned organizations with philosophies incompatible with XP (which reminded me of a book I read called "Cube Farm".) Could there be project incompatible with XP as well? Such as a extension to a quarter million line, hacked together, undocumented (including arcane variable names), decades old, COBOL code? (Also from said book.) [Soren] Also, I worry the implications of comparing, and somewhat treating, the coding process like an assembly-line-like process. I mean, there are some similarities drawn, and is that really how programming should be? Should it feel much like an assembly line? I mean the one thing I can think of is how not ever coder always works on the same section of code, but you do have a lot of individual jobs listed in the earlier chapters (product manager, project manager, tester, architect, coder, etc., etc.) it does seem well on it's way to being specifically specialized and as Assembly-line esque as programming could be. I just wonder: is this really the "best" and "most effective" way to code. I mean, they even want use to leave almost all emotion we have at the door, and I personally believe emotion, especially passion, can bring about some of the best aspects of software. Granted it also allows for things like ego and other emotions to get into the mix, but remember Pandora's box, we may have gotten all these horrible things, but wasn't Hope supposed to be WORTH it? I just wonder if this is the right road we should be going down. In all honesty this is a gross exaggeration, but I'm trying to play the devil's advocate and promote discussion with this question, and I do think it's somewhat important to address the ideas of XP that are much like an Assembly line and wonder: Are these good, or are these bad? [Pat] "Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales." XP argues against having a separate Quality Assurance department. Based on the above quotation, there is an interesting parallel between the way XP says not to treat quality and the way all engineering treats marketing and sales. Would it be better to merge marketing, sales, and engineering together, as XP suggests should be done with engineering and QA? [Alexi] XP revisited ------------ If you were trying to switch your team to XP, what practice would you try to follow first? [Heather] Why do people tend to revert to their old flawed ways of doing things? What do you do if you believe in the principles and values of XP but the company you work for has a very opposite mentality? [Alex] I can't help ask this, but I sort of feel like he gets real preachy towards the end, and that it seems that there is just some extra fluff... could XP programming be explained much more simply? Is there a lot of "fluff" in this book? [Andy]