Extreme Programming With Cpp

[From PairProgrammingInCpp]

Could someone explain to me why there are a proliferation of pages a la FooingInCpp where Foo is some process element of ExtremeProgramming? The general opinion is that doing anything in CeePlusPlus is tremendously impossible. Well, it isn't. Actually, I'd say almost the opposite. So, why is everyone doubting this fabulous KitchenSinkComplete language? -- SunirShah

Because those of us who've done a lot of C++ know how much harder it is to be productive in it. It's easy to think that C++ will fight you on pairing just as well as it fights you in memory management, header file maintenance, and many other areas. -- WayneConrad

Perhaps I don't buy it because I don't find C++ overly difficult. But then again, I've been programming C for 8 years and C++ for 3. Of course, other people have been using it longer than I have. I guess people have problems because C++ doesn't fight you on much of anything. It lets you do what you want to do. With great power comes great responsibility, which kind of sucks when you want to do other things, I suppose. Anyway, enough of the LanguagePissingMatch and onto other things. --ss

I feel the same way. I have never understood why people think c++ programming is so difficult. Sure it has limitations, but then so have most languages. People go on and on about it and I used to sit back listening and thinking, "Am I stupid or a genius? Maybe they're idiots, maybe the code I write is trivial compared to these guys..." I'm much better now. The one thing I have learnt, that XP has taught me, is don't waste your time thinking about it, just do it. --hjm

I spent about a year and a half on one XP project using C++, and about 8 months on a second project. I have also done XP with Java, Python, and .NET, and I can say that XP is more difficult with C++ than these other languages but far from impossible, however being productive in C++ is IMO easier with XP than without it. For example compile times slow down ContinuousIntegration, but that can be a problem on any C++ project. Practicing ContinuousIntegration forced us to consider physical design issues early to keep compilation dependencies to a minimum so that build times were as fast as possible. This resulted in us refactoring toward the patterns described in JohnLakos' book LargeScaleCppSoftwareDesign -- even though most of the team hadn't read the book before the project. Speaking of refactoring, refactoring is more difficult -- not so much because of typing IMO, but because as ss said, you can do just about anything in C++ which means its really easy to get code that compiles and seems to be the same, but has subtle semantic or memory management characteristics. However, having large suites of unit tests, makes doing such changes with confidence possible and almost painless -- and also drives the code toward a really good class design to isolate memory and other resource management so that higher level code doesn't have to worry about low level details (something that some C programmers who migrate to C++ don't naturally do).

So far from saying C++ with XP is impossible, I would argue that its easier to do C++ development with XP -- its just harder to do XP with C++. Just as it is harder to do some things with C++ than language x, but easier to achieve other goals, presumably you have reasons that warrant your use of it. If so, then having a constant peer review, copious automated tests, continuously integrated code, good communication with your customer, a simple and yet robust design and so forth will help you tremendously. -- BillCaputo

As a C++ programmer, I tend to agree that our language is so different from any other programming language that it is impossible to apply the development techniques used by other programmers.

Not really. The language usually has a lot less to do with techniques of design and development management (on an individual level) than many other factors. However, C++ gets to be the whipping boy for a lot of more generalized complaints seeking a target.

[Thanks for the clarification, but the original statement was my attempt at dry humor.]

"For example compile times slow down ContinuousIntegration, but that can be a problem on any C++ project."

I don't know about that. The last project I was on that compilation time had any significance at all was a data collection front end for a digital telescope (Sloan Digital Sky Survey). I was forced to use gnucc on a shared UNIX box with a ton of other users. Even then, with proper make management the build sessions were pretty short; I couldn't even justify getting up to get a cup of coffee. Sorry, but this argument sounds a little like a RedHerring to me. -- MartySchrader, speaking from some experience

1) Saying "compile times slow down CI" has nothing to do with individual projects or languages, its simply a logically correct statement: if it takes longer to compile, then it will take longer to do a CI cycle, since compiling is a sequential part of the CI process.

2) saying can doesn't mean will. C++ projects of any size have to think about physical design issues (as do other compiled languages). C++ isn't necessarily slower to compile than other languages, but there is a lot more latitude in how we do our physical design, so items like header files, file dependencies, use of templates, choice of compiler, use/abuse of libraries (e.g. ATL), etc. become our responsibility, not the language's responsibility. So the second part of the statement is: if you don't think about your physical design in C++, then you may end up with lousy compile times, particularly on large projects. CI is a very visible, systemic process that occurs several times a day which thus strongly encourages the team to find ways to speed things up. Thus, CI has a positive impact on C++ physical design by providing even inexperienced C++ teams objective feedback on the quality of their physical design. -- BillCaputo

How does Continuous Integration affect compile times? I doubt even the most ardent XPer in any language synchronizes his files every build, so I don't see how this would affect C++ programming in the least.

Very good theory, but doesn't match my experience. We do synch files every build, this was true of all 5 XP projects I have done (two were C++). On one 40 person 2 year project (15 C++ programmers) we each checked-in (which means synching with the entire code base) 2 - 4 times per day, doing on average about 10 builds per day (full builds, plus two sets of tests, plus repackaging and document generation). In addition, each person did incremental build/test cycles on their machine every 10 minutes or so. Keeping this cycle from slowing down (and thus negatively impacting our productivity) meant addressing physical design questions early and often, which had a very large impact on our design decisions. Not everyone was experienced in large-scale C++ design (I wasn't), but all of us could see that we didn't want to recompile 5 classes while working on one class, so patterns like DependencyInversion starting cropping up early - but not where they weren't needed (thus we didn't BDUF the physical design either). Take a look at QuickFix's build pages for another example of C++ CI (and incremental design) - we synch and build that project on 4 different platforms with every code change. -- BillCaputo

I believe this repeats what I said. It is noted that "we each checked-in (which means synching with the entire code base) 2 - 4 times per day", but "each person did incremental build/test cycles on their machine every 10 minutes or so". Assuming the developers worked more than 20 - 40 minutes a day, the developers were not synchronizing every build. Checking in and synchronizing 2 - 4 times a day seems about right and what I would expect in any other language. What aspect of C++ makes 2 - 4 synchronizations a day more onerous than in any other language?

Because its not just 'synching with the repository' its synching, compiling, testing, packaging and deploying two to four times per day, so all of the physical design freedom one has in C++ - if not handled properly - can adversely affect build times (as can many other things, not related to C++). I sense that you think this is some sort of attack on C++, its not. Its just a fact of my experience: poor C++ physical design can adversely affect compile (and thus CI) times - not in comparison with some other language, just on its own. I really like programming in C++, and I think it marries just fine with XP, but I am not going to ignore the physical design needs of the language, or how they can impact CI, just because it might sound like I am not adequately glorifying someone's pet language - that's how languages get a bad name, and possibly how those who don't think C++ is appropriate with XP, got their misperception: their expectations didn't match the needs of the tools and practices. YMMV -- BillCaputo

I still fail to see what is unique about C++ in this regards. Synching, testing, packaging, and deploying would seem to be language independent tasks. As for compile and link times, I have not seen noticeable differences based on language and only significant differences based on vendor.

Yes it is clear that you fail to see, I think its best if we AgreeToDisagree. -- BillCaputo

How does Continuous Integration affect compile times? I'd still like to see this question answered - I suspect that it does, but I'm not sure in which direction. A single developer working in a tight testing cycle - so she will be trying to arrange that the incremental build between tests is small. She doesn't want to pay any penalty for rebuilding code she hasn't touched, so presumably she breaks as many physical dependencies as practical. So the project gets broken up into many small modules, using Lakosian techniques.

So what happens when you try to integrate continuously with her? When you get her change, it is very small physically; once you have the diffs it is quick to build. But if your source control system needs to check each file for changes, then a dramatic increase in the number of files would slow the update portion of the ContinuousIntegration cycle. So I suppose that, if the needs of ContinuousIntegration are given preference over the build times, that it could provide some negative impact.

I rather strongly suspect that this effect is negligible, that ContinuousIntegration has a negligible effect on compile times in C++. What have I missed? -- DanilSuits

(Wow, long time since I visited this page) To clarify: Deciding to practice ContinuousIntegration (with any language) means you will be very aware of your build times. With C++ in particular there are strong daily (hourly?) incentives to (re)visit your physical dependencies in order to find ways to reduce them (since they tend to be the biggest build time inflator). In short, there is no effect beyond lots of feedback, and the pressure that brings to reduce compile time - but this can be enough to produce the desired result. Presumably, teams not practicing CI have higher pain thresholds for build times (since they don't do it as often) and thus have less incentive to address physical dependency issues until they are bigger. -- BillCaputo

ContinuousIntegration with C++ is possible. See for example MozillaTinderbox. Also, JohnLakos covers build times and physical design very well in LargeScaleCppSoftwareDesign. His book could just as well be titled "Refactoring in C++", and is an excellent read.

See: RefactoringWithCeePlusPlus

CategoryCpp, CategoryExtremeProgramming