You will be presented with the full text of a science research paper. Please write an abstract for this paper. Your response should include the abstract and no additional text.

Paper text:
the cdf offline involves hundreds of collaborators from 56 different institutions from all over the world .
while not ever collaborator has directly contributed software , all must use the software and help debug it .
the current code set consists of tens of millions of mostly c++ code , organized into 294 packages .
these packages are further organized into major reconstruction , simulation , and physics categories : tracking , calorimetry , muon , time of flight , luminosity counters , top , tau , electroweak , b physics , and infrastructure . at cdf
the offline includes all of the software and computing need for the real time software trigger ( the level3 trigger ) , the online monitoring of the detector , the primary reconstruction , the detector simulation , physics group analysis software , tools such as the detector event display and software used to measure the performance of the above , such as tracking efficiency and purity .
in 1996 when work on the run 2 offline started , very few people at cdf knew c++ .
the advantages of using a language that supported memory management was considered large enough to out way the cost of learning c++ .
we claimed that we would start by writing all of the infrastructure code in c++ but still make provisions for the physics code to be written in f77 .
people involved with the run 1 experiment wanted to reuse as much of the run 1 code as possible , so the code was wrapped into c callable routines and fed it s input data via the c++ infrastructure .
output was in the form of arrays that were also managed by the infrastructure .
as new people entered the project there was a desire to replace this code with algorithms written in c++ so that it would be maintainable .
this happened for every subsystem until everything was c++ .
the next generation of maintainers after this second round has not felt it necessary to rewrite everything .
we now have people entering the project with prior c++ experience from other experiments . during the development of the code we never had enough people to work on all of the tasks
we wanted done .
strong leadership to prioritize during these early times was essential . at any one time we had about 6 to 10 highly productive developers , one per subsystem .
the release schedule reflects the pace of development and managements decisions about how to best serve our users .
our users were the detector commissioning physicists , and farm and data handling hardware developers . during the first year that we started making major releases , 1999 , there were 5 releases reflecting the difficulty of these first integrations . in 2000 and 2001
there were about 10 each year .
this was our time of extreme programing .
many of the major rewrites occurred at this time , including a change from a fortran array based edm ( event data model ) to a root based edm . at the same time
the experiment was commissioning the detector and these customers required that we keep the code working for their use .
for this reason many subsystem developers were maintaining two versions of the code for their system .
one of the advantages of this situation was that both versions could be run to see if they resulted in the same answer .
many bugs were discovered while investigating differing answers . some were in the c++ but
some were found in the run1 fortran code as well . in 2002
there were about 5 releases .
this reflected the need for stability in preparation for presenting physics results at the early 2003 winter conferences .      throughout the history of the project cdf was greatly aided by using the work of others outside of cdf .
babar donated their framework , evtgen and ideas .
the support of the root team especially phillippe canal was essential .
many of the zoom / clhep classes we use were developed by those groups at our request .
many of the classes in existence before cdf started developing c++ software were greatly improved in performance through collaboration with the supporters of clhep .
unfortunately our compiler vendor , kai was also a collaborator in that we had to report bugs to them . despite this ,
the decision to use kai was not a bad one .
it allowed us to write c++ standard code much earlier then we would otherwise have been able to .
this has served us well in transitioning back to g++ now that kai is becoming unsupported .
the most important step in creating stability and robustness in the software system was the development of rules and procedures .
there are rules about how releases are put together and what can be integrated at different phases of the cycle .
there are well defined procedures for validation and regression testing of all new releases .
these are documented on the web and the manpower for doing these tasks comes from the collaboration as part of an offline shift .
a shifter is given recipes for running purify , debuggers and software management tools as well as instructions for running the tests .
monitoring the running of automated systems like the reconstruction farms is also part of the job .
use of a bug tracking tool has also greatly aided in finding problems and documenting solutions for out users .
the shifter can try to answer questions that are sent to the list , or forward them to the relevant system expert .
here is a list of some of the things that were surprising and were learned over the course of the project :    * you never really understand a problem until it is solved once .
the strategy of studying and recoding run 1 code in c++ for run 2 served us well in many areas of the project .
* performance has not been a problem , wasteful copying was eliminated early in the development of the code and there are still gains that we can make . choosing efficient algorithms gains more performance the hand optimizing the code . *
keep the system clean in terms of physical design and organization .
physics analysis codes will follow the patterns of the reconstruction and be more generally usable if the reconstruction is kept clean . *
a code browser is important for both the developers and users of the software system . *
beware of code generation , it can produce code bloat if not done carefully . *
memory leaks are supposed to be the biggest problem in large c++ systems , however for us uninitialized variables has been a bigger problem .
memory leaks can be traced with standard tools .
uninitialized memory reports from these same tools are too numerous to be useful .
many of these reports are completely harmless and finding the bad ones buried underneath is very hard .
we have had releases in which the farms operation of the reconstruction was tested to be 1 crash in a million events .
the same exact code when recompiled with a shorter name for the file system it lived on crashed in less then a thousand events processed .
this was traced to an error in using uninitialized memory . * start commissioning as early as possible .
mock data challenges did nt completely prepare us for the turn on of real data .
count on having to change things once you have really customers with real needs .
* many people will leave the project one year after the first physics data arrives .
if faced with the choice of two solutions to a problem always choose the most maintainable one .
insure that there is sufficient overlap between the original developers of the code and the junior people who will take over the maintenance of it .
the cdf offline software system was flexible and serviceable .
it was able to help commission the detector even while it was undergoing large transitions to improved software .
it helped take the data , reconstruct it , and perform the physics analysis on it in a timely manner .
cdf ii is one of the two large collider experiments at fermilab s tevatron . over the past two years 
 we have commissioned the offline computing system . a task that has involved bringing up hundreds of computers and millions of lines of c++ software . 
 this paper reports on this experience , concentrating on the software aspects of the project . 
 we will highlight some of the successes as well as describe some of the work still to do .