Hi Vincent, > All that said, I agree there's a fine line that we > should not cross, i.e. when automation is telling > too much the developer what he should be doing. Your > stance (and other XPers on this list) is that this is > crossing the line.
Indeed, I wholeheartedly agree that tools should simplify and automate, rather than dictate, developers' work. However, my objection to your proposed system was different. Basically, I was pointing out that there is no need for it on an XP project. The problem it attempts to solve does not arise on an XP team. My previous XP team seemed to break the build at most once a month, and it was usually painless. Now, considering your non-XP/large team context, I've tried to come up with some rational arguments against your system: 1) Having a broken build is annoying, but fixing a broken build takes time. By /protecting others/ from the consequences of a broken build, your system is also /preventing them/ from learning from it. Given the environment you describe, I would expect developers to fix the build without necessarily warning others of the root cause. Fewer people will be thinking up solutions to avoid it, and several people will be wasting time fixing similar problems independently. 2) You describe an human context in which breaking the build is not a big deal. It seems to me that a system which prevents a broken build ever being committed makes it even less of a big deal. It seems to be going in the opposite direction of the XP/Lean phenomenon in which the whole team stops everything and fixes the build, because breaking it is a BIG DEAL. 3) Your system is asynchronous, and you actually point out that this enables developers to start on a new task while the commit is being checked. I fear this would remove any pressure on keeping the build fast, and engender costly context-switching situations when the commit fails. 4) A corollary of the above (slow builds and context switching) is that developers will avoid committing too frequently, and as others have pointed out, this is a real problem, and indeed seems to be the opposite of what your system is meant to promote, i.e. /continuous/ integration. > BTW, this is exactly what the unbreakable build > solution would do for you: show you exactly what > broke the build. Not if developers commit less frequently: the key to knowing exactly /what/, as opposed to exactly /who/, broke the build, is frequent commits and updates. > Example: StarTeam (SCM) does not show you the file > you have added to a new directory. Thus when you > commit, developers systematically forget those files > as they do not appear in the StarTeam's view). Using a separate integration workstation, like on C3, solves this, while at the same time providing a natural serialization mechanism. Regards, Dominic Williams http://www.dominicwilliams.net ---- To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
