my dog learned polymorphism*
The moose likes Agile and Other Processes and the fly likes XP and Quality Procedures Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "XP and Quality Procedures" Watch "XP and Quality Procedures" New topic
Author

XP and Quality Procedures

Sowmya Karmali
Greenhorn

Joined: Mar 30, 2001
Posts: 10
I just got aboard the XP ship about a month ago, and I have been wondering about a few things.
XP advocates refactoring of code,changing and throwing away unwanted pieces. One area which takes a beating on this one is configuration management. For instance, you designed a class 3 weeks ago, which is now about to be chucked out, which you may bring back next month. Is there any way to regulate this, so that we utilise the benefits of both?
Another thing is the absence of reviews. Yeah, pair programming is certainly good(and I have seen the benefits myself, being part of a pair), but this does not mean that we don't need walkthroughs. Is there any reason for reviews to have been left out of XP?
rgds,
Sowmya.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4474
    
    6

On configuration management: All you need is a good CM software like CVS or PVCS or MKS Source Integrity or even M$ SourceSafe. One of the benefits of refactoring is that you maintain a good design at all times. A good design actually helps you do better configuration management.
On walkthroughs: When done properly, pair programming is when the code review happens. This is supported by the unit tests which must pass 100% and the functional tests. With these three practices, why would you need a walkthrough?
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 03, 2001).]


Junilu - [How to Ask Questions] [How to Answer Questions]
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
Originally posted by Sowmya Karmali:
I just got aboard the XP ship about a month ago, and I have been wondering about a few things.
XP advocates refactoring of code,changing and throwing away unwanted pieces. One area which takes a beating on this one is configuration management. For instance, you designed a class 3 weeks ago, which is now about to be chucked out, which you may bring back next month. Is there any way to regulate this, so that we utilise the benefits of both?
Another thing is the absence of reviews. Yeah, pair programming is certainly good(and I have seen the benefits myself, being part of a pair), but this does not mean that we don't need walkthroughs. Is there any reason for reviews to have been left out of XP?

I don't understand how configuration management takes a beating in XP. Certainly you need to get a configuration management tool and use it. XP doesn't make using it any harder. XP does advocate using a concurrent edit tool, like CVS, rather than one that uses locking.
You can still do reviews in XP, but you need them much less due to the pairing, refactoring, and collective code ownership. So XP doesn't include them as part of the formal process. I still find it useful to have broader discussions from time to time.


author of:<br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/electricporkchop" target="_blank" rel="nofollow">Refactoring : Improving the Design of Existing Code</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/electricporkchop" target="_blank" rel="nofollow">UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201895420/electricporkchop" target="_blank" rel="nofollow">Analysis Patterns : Reusable Object Models</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/electricporkchop" target="_blank" rel="nofollow">Planning Extreme Programming</a>
Sowmya Karmali
Greenhorn

Joined: Mar 30, 2001
Posts: 10
Configuration Mgmt:
I am talking of using a CM tool. I believe in refactoring, but I'm afraid that we end up with too many unused ( used in the future?) configurable items. Consider that you have a class which you shelf, but it is still a configurable item as per the tool. And if you have a client who wants the source, try explaining to him why these classes are not being used/delivered. It could be that we're not following a proper refactoring methodology and that's how we ended up in this situation. Can anyone suggest a refactoring approach?
Reviews:
I think a inputs to refactoring could arise during a review process. Even with pair programming, it would be effective to have a designer review the code at least once. I feel that PP is not the answer to reviews, they should go hand-in-hand. Moreover, quality audits ( like ISO and SEI) do look for review records.
Sowmya
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Why would a client ever know or care what is in the CM tool? A CM tool is like a corporate repository which obviously holds more than the source for a single delivery. Our CM systems usually hold several projects, each of which has many deliverables. That's why all sensible CM tools allow you to specify which files are included in a delivery.
If you want to give the client a source-code drop, you extract the current source for a particular deliverable from the CM system and give it to them - they get the complete source for the associated executable delivery. The fact that the CM system might also contain source for other projects or other deliverables is surely immaterial.
Or have I also misunderstood your requirements?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
Originally posted by Sowmya Karmali:
Configuration Mgmt:
I am talking of using a CM tool. I believe in refactoring, but I'm afraid that we end up with too many unused ( used in the future?) configurable items. Consider that you have a class which you shelf, but it is still a configurable item as per the tool. And if you have a client who wants the source, try explaining to him why these classes are not being used/delivered. It could be that we're not following a proper refactoring methodology and that's how we ended up in this situation. Can anyone suggest a refactoring approach?

A CM tool will keep everything you've ever done. This is important to use. If I see a class or a method that isn't used I just delete it. If someone says "but we'll need that next week", I just reply "it's in the CVS - we'll get it back when we need it". It's valuable to have that mechanism of every change you make.
Every time you build, tag the files in the build with your build number. If someone says they want the source for build 452.7 then you can just pull everything with that tag out of your CM tool. You say anything about what's been altered, constant change is a standard part of software development - that's why we have CM tools!
Ram Ramanathan
Greenhorn

Joined: Apr 15, 2004
Posts: 1
Let's talk a bit more about Refactoring.However it is defined in theory, when put in practice, especially in a framework based development environment, one better be sure why and how the refactoring has to be done.
The rules governing the refactoring have to be very clearly defined. If a valid refactoring done, I don't see any reason why a class that was thrown out a month ago should ever be reinstated. & refactoring is not just about deprecating classes.It could be deprecating a whole set of artifact(s) in the architectural framework.It could range from modifying the signature of a core component's method to make it more generic & reusable by other functions or moving components between layers(making them more or less shareable).
Such a decision could have refactoring complexities ranging from
a) running a search for all the classes in ur codebase that use this component and just changing the package reference wherever this component is referenced(compile time)
b) Widespread changes to ur code possibly coz some of the classes that were accessing this component before cannot now access it the same way due to component access rules imposed between layers and tiers.
Imagine this happening frequently in an architectural framework used by say 300 developers and if one developer were to unilaterally do such refactoring,it could potentially impact 300 other classes and he may not even be fully aware of the impact, lest he may be doing a partial build.
No matter which CM tool u use, the impact of refactoring has to be very clearly understood by the owners of the architecture/development framework and very strictly controlled. I for one believe that refactoring should never be rampant.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Regarding the code reviews, I am a huge, huge fan of code reviews. I have personal data backing up the research that says code reviews catch more bugs than tests (and I always test). I always try to get the manager to require code reviews or strongly encourage them, and when I'm the project lead or manager I impose them as a requirement - and before checking the code in, too. Even when working on one man projects, I'll impose on friends or even my wife when I have code that I feel could particularly benefit from reviews.
All that said, I think code reviews are superfluous when pairing.
Think about what pairing is: one person is at the keyboard coding, the other person is watching over his shoulder, making suggestions. That's exactly what a code review is - except in real time. If you use pair programming, then by the time you've finished coding, you've already got your code review!
Note that code reviews are different from walkthroughs. In my experience, walkthroughs using a debugger can be very useful in understanding how your code actually operates - which is not always the way you thought you wrote it. But there's nothing that says you can't do walkthroughs while pairing - or that you can't run the unit test in the debugger.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Well, the best way to be aware of the impact of a refactoring is to have all the clients source in your IDE and let it determine the impact. Works very well for inhouse situations.
Of course it gets more complicated when you don't know about all the clients. With some experience you might be able to reduce the need for those refactorings by using sound design principles to better decouple the API from implementation details.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
We just rearranged some packages, and it was a big headache for developers for a day or so. This is 100% our fault - our scripts and proceures require manual changes to match the packages, and changes don't show up perfectly in everyone's copy of the code. Agile practices require agile CM and if you aren't ready with that, you can hurt yourself.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
GeeCON Prague 2014
 
subject: XP and Quality Procedures