If you come seeking light-hearted poetry, stop now and go to last week's post. This week I have only prose about Agile and a little bit about C++.

To give credit where credit is due: The lyrical structure of last week's post was written by Sam Smith, who recently wrote a song: https://www.youtube.com/watch?v=auXMPle74To

Maybe I should start doing more poetry. Because I could not write C++, C++ kindly wrote for me? I dunno.

Friday in class I had an epiphany: C++ was written like C, in the sense that you can intimately control the mechanics of classes.

With this in mind, C++ starts to make a lot of sense.

That's all I have about C++. This week's reading was about various development strategies and the practice of continuous integration. CI should be done everywhere, no exceptions.

Agile has been referred to as "The New Methodology", which I feel puts a slight bias towards it. It's "New"! It must also be Shiny and Good!

The essay we read (http://www.martinfowler.com/articles/newMethodology.html) makes a pretty decent argument that "Agile" programming is the appropriate way to code if you don't have any requirements. Unfortunately, "Agile" doesn't really mean anything, although I guess it'd be like most marketing terms in that respect. "Synergy" comes to mind. "Agile" just refers to any programming practice that's full of coders who don't know what they're doing, so they make it up as they go. They formalize it in these "sprints".

I'm not against that practice per se, that's how it's been done everywhere I've worked. I am against using rediculous terms for no reason.

For instance, "information radiator", which is just convoluted jargon for "post-it notes." Maybe some of us should get together and synergize to construct an information radiator that clearly and concisely communicates informational messages about the convolution appearing on the "Agile Software Development" portion of the globally-distributed-editing paradigm existant on the decentralized topography of the Internet.

I'm surprised nobody else has done this already.

I'm also against pair programming. In this class we get a lot of experience programming in pairs. My experience has been that pair programming helps for the first two hours (or thereabouts), and then becomes pointless. In these first two hours, the design is fleshed out and very little useful code is written.

After the first two hours, it becomes one person implementing trivial functions while the other person tries not to fall asleep.

Take this code from a previous project for example:

TEST(SpeciesFixture, species_handles_label) {
    Species s(1);
    s.addLabel("start");
    s.addInstruction(Hop, 0);
    s.addInstruction(Goto, "start");
    int pc = 0;
    struct VisibleState vs;
    vs.empty_ahead = false;
    vs.wall_ahead = false;
    vs.enemy_ahead = false;
    ASSERT_EQ(s.execute(pc, vs), HopAction);
    ASSERT_EQ(s.execute(pc, vs), HopAction);
    ASSERT_EQ(pc, 1);
}

This code tests to see whether labels work in our instruction executor ("Species").

Once you say that single line of English, it doesn't matter what the code looks like. It doesn't help to have a second person watching someone write it. If one person writes it, she will compile it and see if it works. Having a second person only slows her down: A second person might say, "well, all the vs. lines could be combined into one line," and now she has to stop and they have to have a conversation about which is better.

Once you get past the high-level design, two people at a computer stops being useful. Some people say that it helps reduce bugs, but so does good design and good testing.

For example, the Space Shuttle Software Group does not use pair programming, but rather uses good initial design. They have, on average, 1.5 bugs per software release (280,000 lines of code per bug) compared to the average commercial software which has 5000 bugs per software release (84 lines of code per bug).

One could argue that the SSSG is exceptional, and they are, that's true. They're also in a somewhat different industry that demands a more safety-critical approach than, say, a video game engineering team.

Point is, don't promulgate pair programming. It's just as effective as having one person write the code, then having another review it via a pull request.

Which leads me to the Tip of the Week: Know how to review code! Also know what a pull request is. Unfortunately you don't learn these things in this class (CS371p), but perhaps find an open source project on Github (there's at least one that uses C++) and contribute or, if you don't feel like doing that, spend some time away from your Life partner submitting PRs (you're allowed to spend 25% of your time on the project coding separately, more if you're willing to lie).

This is an image of me doing what I do when I'm not at a computer.