The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

dependency management

I just joined a company that develops two large Java products . We are about 60 to 70 people following agile methodologies and extreme programming techniques. One problem I have noticed is on dependencies. Someone changes something somewhere that leads to failures of the automated unit tests later in the night when the build is made. The errors are detected of course almost the same day, but I am figuring out a way to avoid it in the first place. So, as it may make sense, I would like to maintain some form of dependency graphs, lists or whatever that will hint me of my dependents before I make a change to a particular component. For this I may have to explore some tool such as JDepend which I just found.

I was looking for any expert advice on this topic before I explore and figure out my own practice.
brett
Monday, July 10, 2006
 
 
Can't you sync the whole tree and use the refactoring features of your IDE?

Or sync the tree and run the unit tests before checkin and fix the problems you find before submitting your code.

Or try using some standard OO techniques to reduce dependencies. Oh, sorry, you are agile and can't do that advance sort of programming the other people waste their time on.
son of parnas
Monday, July 10, 2006
 
 
Well, first of all, congratulations. Just getting to the point where you're doing daily automated builds and catching problems right away, is a major accomplishment. Don't underestimate the competitive advantage that gives you.

Now for the bad news. With 60-70 people on the team practicing agile/extreme development, your code base changes very quickly. Assume for the sake of argument that you did have such a dependency management tool. It's quite possible you'll check the tool at 10 AM, make a list of what you'll have to change, check again at 2 PM and discover your original list is outdated and inaccurate. In essence, your dependency list is a moving target.

I think it's better for you to stick with your practice of having people "stop work" at the end of each day and then find all of the problems that need to be fixed at once. Figuring out exactly what changes should be made, is something you do the next morning at the daily 10 minute meeting.
TheDavid
Monday, July 10, 2006
 
 
Umm ... I hate to state the obvious here but ... why not make a complete build a condition of check-in. Shouldn't the dev making the change build the entire tree locally first, to ensure tonight's centralized build won't break?
Sgt.Sausage
Monday, July 10, 2006
 
 
Actually, I would suggest changing how often/the size of your builds.

Sure, a complete set of Unit tests might take hours - most don't - but a simple smoke/compile test normally takes much shorter.  Therefore, you might be able to run it over lunch.

Alternatively, if you have the ability to split it into smaller modules, you might get into hourly builds.

This does *not* solve the dependency checking for you, but it does allow you to figure it out much faster.
KC Send private email
Monday, July 10, 2006
 
 
thanks gurus; will brainstorm your points further
brett
Tuesday, July 11, 2006
 
 
Implement a systemic dependency-management policy: there is no alternative.

See:
http://www.edmundkirwan.com/fracdoc/frac-page10.html
Ed Kirwan Send private email
Friday, August 04, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz