Integration Hell

Now we have to integrate them to build a new system. Carl's code, as usual, breaks everything. It looks to me as if you have a few problems too. My code is solid, I know that because I worked hard on it.

What I can't understand is why you think there might be something wrong with my code, and Carl, the idiot, is after both of us.

We're in for a few really unpleasant days. Maybe next time we shouldn't wait so long to integrate ... --RonJeffries

The above description has been edited for family content.

It's as close to IntegrationHell as a sunday school class is to a mosh pit. --PhlIp

(for others who don't know what a mosh pit is see http://members.aol.com/rik0lar/moshing/mosh.htm)

Often performed just before BigBangTesting.

Assembly Required

Reminds me of putting together some Assembly after purchasing it, opening the box, spreading the parts out in clear view, and then beginning the job with the instructions thrown aside. Almost everyone has experienced this. "When all else fails, read the instructions". How much easier it is if we use the right part in the right place.

"Maybe next time we shouldn't wait so long" -- Seems to present a good argument for planning. If indeed parts of a assembly will go together, they must fit, with the right part in the right place. To proceed without a plan is to fail without a plan. To make things fit after the construction of the parts when no plan for connection or fitting together has been made is a planningFailure. Each of the parts may be perfect in isolation, but the fact that they should work when put together has been neglected. That is what specification and planning enables.

Revenge

If you are the person whose responsibility it is to get everything integrated, you may have some nasty thoughts at 3:00 AM when you are trying the sixth full re-build of the evening after fixing yet another set of build errors caused by check-ins of buggy and incomplete code by your valued co-workers. To entertain yourself while waiting for the next round of error messages, consider the following actions:

• Remember to give everybody a friendly thank-you phone call at whatever time you do finally get a working build.
• The films "Silence of the Lambs" and "Hannibal" have good ideas for clearly and directly expressing your feelings.
• Practice your CompulsiveCustomizer skills with their machines.
• Write up a new set of CodingStandards, with very specific advice. Be sure to name names.
• Write up job descriptions for currently-occupied positions that you think need to be made vacant, and post them to the company's employment-related web pages.

Less tongue in cheek advice: Don't fix the problems. As a manager, I recommend this to my people, if someone checks in code and it doesn't work, go find them and request he fix the code. If he has left for the day, send an e-mail so that he can fix the problem the next day. If the person is on vacation or out sick, roll back the changes to the last working version and go with that. It is part of our development process to build and unit/regression test before checking in code. Don't cover up someone else's mistake. Make him responsible for fixing it.

Good advice, but could be incompatible with CollectiveCodeOwnership. Occasionally, you really do need to get a build ready for the next day, and you are the only one who can/will do it, and there is no sense in refusing to do it just because it is SomebodyElsesProblem. On the other hand, don't be a silent little gnome who constantly works overtime to single-handedly keep everything working. Let people know what you had to fix so that they won't make the same mistakes again, and make sure the IntegrationHell experience is shared with others (especially with those who are most prone to cause the problems).

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006