| supposedly, an XP programming team strives to mantain the invariant that their code is self-documenting; i.e., the source itself provides the documentation, through clear variables and clear algorithms. the reality is that most programmers gravitating towards XP don't have the discipline to follow such guidelines. deadlines can do more to muck up code than anything else. in my experience, XP programming results in code that has to be refactored if it's ever going to be of any reuse. i've heard stories of people creating 27 anonymous classes in a java project, for instance (you nooch!). alan fay |
| Actually, XP says that you comment a method only when you can't think of anything else to do to it to make it more readable. This doeesn't mean no comments. Barbara Ericson |
| the kind of code you throw away anyway, because it's garbage. :) seriously though, XP is referring to the practice of group-motivated source code, or code generated by a team of people. the idea is that, given a good enough group of people, the code produced by the group tends to be more like code that can be read and mantained by anyone. yeah, good luck. (in case it isn't obvious, i'm not in favor of XP). trust me when i say getting four individuals to adhere to a common style of programming is impossible, at best. the code turns in directions that no one is familiar with; a couple of programmers decide to circumvent the others' code, and the others rewrite something first two had working, and break it. and these are just a few of the more fun scenarios i can think of. :) ideally, if a group of people knew what they were doing, and got along, then the product is useful, mantainable. but this is just an ideal. alan fay |
| XP requires pair programming not large group programming. Barbara Ericson |
| this however, is actually something useful. integration of distinct components of software is usually a completely independent, difficult task. daily integration can help to shift attitudes. for example, two separate groups work on components for a software. both groups independently say, "as long as my stuff works great, there's no problem." then, it comes time to interface the two and a fight breaks out. it's almost like another program has to be written to join the two pieces. daily integration solves this, by creating the atmosphere that says, "it's a part of the day's work to resolve interface issues as we encounter them." the time spent doing this, over time as attitudes improve, will be minimized with respect to the scope of a grand integration at the end of the program. alan fay |
| XP requires something that makes regression testing easy and quick. What is it? Barbara Ericson |
| are you referring to unit testing? marilyn cole |
| i recall back in 2335 a lecture slide that looked exactly like the slide from 1311 that compared O(N^2) and O(log N), but the axes were labeled different. so there's some empirical evidence somewhere that has shown XP outpreforms other software engineering methods. however, the success of XP seems to only ride as far as the ability of the individuals practicing it. a group with good chemistry can accomplish many things; but such a group is rare. alan fay |
| See the slides for XP for a better answer Barbara Ericson |
| I believe that Lucent Technologies has implemented XP and they say that it has shown a definite improvement in their development department. - Jim McPherson |
| Lucent is bankrupt–both financially and morally Suleman Ali |
| also, there was a study by laurie williams, which tracked pair-programming vs. traditional in two classes. while the pairs started more slowly, by the end they had more "function points" completed, fewer bugs, and had taken less time! [straight straight from the lecture slides.] marilyn cole |
| also, there has been another study on pair programming by a polish |