- Pair programming
- Continuous integration
Spent more than a decade working remote, from home. Built some significant software. Raised my kids (after a divorce). Became somewhat disconnected.
What is labeled as “Agile” programming became a fashionable thing.
Pair programming Pair programming is one of the fashionable myths. Does not work for me. A few minutes thought turns into several times longer explaining what I just did and why. Horribly not efficient.
I do have one example (almost forgotten) where it worked, and well. Joined a research project as an undergraduate at the University of California, Irvine … simply as it sounded like fun. One weekend, quite by chance, found another member of the group in the computer lab. He was trying to build a parser for (then new) the Ada programming language. He was typing, I was following, close. “Yes”. “No.” “What about…” was the main exchange. This was not a practice that (then) had a name.
Two bright minds racing in parallel. (Average minds do not find their way into research projects, as undergraduates.)
The next week, we had a large part of a parser for Ada. A few weeks later, we were amused when one of the reviewers for the Ada language proposals claimed a recursive-decsent parser for Ada was not possible. We had built a working recursive descent parser for Ada, so knew he was wrong (though not without difficulty).
As a practical matter, you are never going to get two folk like me in a group. Pair programming is unlikely to work for me.
But most programming groups are built out of more average folk. Get two average folk reviewing their combined work … might work.
Pulling together a groups’ work, and applying tests on regular basis, sounds like a good notion. I do not work that way.
As an acquired practice, I always do developer-testing before inflicting my software on other folk. Developer testing is opportunistic and episodic. I test what I have changed, focused to (near) only that. I test for zero, one, and many. I test for basic success and failure. In effect probing a few chosen samples from the entire possible space. Turns out, this limited sample is remarkably effective.
The dogma of continuous integration is that if you drop your changes into the common space, problems will be removed earlier. I do not follow this. I built focused tests along with new code. I dropped my changes into the common pool, only when the tests passed.
At the end of a development episode, only when all my tests were passing, I dropped my code into the common pool. What that meant is I was dropping thousands of lines of new and changed code, near the end of a release window. This freaked out some of my coworkers, as they “knew” large changes meant instability in to common code. A usually-right expectation, that was completely wrong in my case.
As it turned out, my additions made a negative contribution to the bug count. (As I regularly found and fixed regressions in the common code, in advance of all others.) My scary-large commits made the entire codebase more stable. This is not what the common myth predicts.
Developer tests, and a strong emphasis on early quality largely oviate continuous integration.
Superprogrammers Read the book “Mythical Man Month” from Fred Brook, quite a while ago. Never really believed in the 10x bit. But recent experience offered a sort of confirmation.
To be clear, I do not write email insanely fast. I do not write “Hello World” ten times as fast. For day-to-day tasks the difference is not large.
Going from the starting point to a working solution is like finding a route across an unknown map. Put simply, I tend to find a more direct route, and get lost less. My day-to-day progress may not be dramatically different, but the more direct route makes a huge difference. The end result, over the longer term, is close to 10x.
Meetings Average programmers tend to get lost, on the path from start to solution. Get enough folk together, often enough, and they might get lost less.
I rarely get lost. From the start of my working life, meetings were mostly about sorting out the confusion of others. Tedious.