Archive: Software

In 2012, I began collecting thoughts and learnings from pair programming in a long document that I thought could one day become a book. Last year, when engineers at Promptworks asked for some pair programming resources, I circulated the manuscript internally. Jon Long saw its potential and tipped off Katel LeDû, the CEO of A Book Apart, who got in touch about making it the next title in their Briefs collection.

The last connecting flight between home and my college was on a comically small airplane. It was a 1996 Beech turbo-prop with no lavatory, no overhead bins, and 19 of the tiniest seats you’ll ever see. About 10 minutes into the 45-minute flight, the copilot would crawl out of the cockpit and serve drinks to the handful of passengers aboard. He could barely finish opening everyone’s cans of soda and handing out the peanuts before needing to return to the cockpit for landing.

Over on the Promptworks blog, I wrote a short piece on how software, by its nature, is never “done” because there are always new ideas and changing business requirements that move the goalposts—and that’s not a bad thing! What can be detrimental is to not accept the nature of software and expect it to conform to a construction project paradigm. By doing so, you miss out on a lot of value and create fragile expectations.