1. Software Development in B A B AR Neil Geddes Rutherford Appleton Laboratory

2. BACKGROUND BaBar  CP violation experiment at SLAC Approved 1995 Start May 1999, run for 5-10 years Software  Learn from experience and the software industry  Computing Group proposed OO in C++  Accepted by the Collaboration

3. OO Program to interfaces  Polymorphism  Hide the representation  Separate data and algorithms Code Re-use  Separate data and algorithms Abstract data types  Objects

4. C++ Not the real issue  Software is only written slowly Why C++ ?  Only viable choice for large OO project. But  Learning new language Language choice does affect design decisions  No language Standard  Complicated language

5. BaBar Walk before we learned to run  Break problem into manageable pieces  Infrastructure to support developers Early prototype - Analysis/user interface in 1996 “Learning while doing” Extensive training of core developers Continued user training  BaBar Mock Data Challenges Could do better !

6. LESSONS Core Team  Must have a core team of principal developers  Regular and frequent contact Infrastructure  Support requirements will be underestimated  Burden increases as some power of platforms distribution of users and developers overall project size  Failures here will impact overall project design...

7. TRAINING Developers  Importance can not be over-emphasised Users  C++ and OO new to HEP  This is perhaps the real issue with language choice Better software vs effort and complication

8. THE REAL ISSUES Software development is free Isn’t it ? We are scattered all over the world  Complicates the project management and support  Central decisions have wide reaching consequences So what are the real issues ? ResourcesProject Management Resources and Project Management

9. CONCLUSIONS Did we make the correct decision in 1995 ? OF COURSE WE DID!