Comments on Understanding Software

Nat here – you're reading my weekly newsletter, Simpler Machines.

Trying out Monday as the publishing day– and trying to keep this one short.

Last week C J Silverio posted slides from a presentation they gave recently about "how software gets made." The audience was primarily people at their company who aren't directly involved in software making – this is an explanation for folks who aren't on the team but work with the team.

I thought it was interesting both because of that audience, and because of the information it contains about Ceej's background –

I need to caveat all of this: My answers to these questions come from a specific perspective– me & my career experiences. I am not going to talk about how it’s done at Google or Facebook or other weird gigantic companies. Going to talk about how software is built by small to medium sized teams, in the Silicon Valley, ones that happen to have a lot of ex-Apple product influence.

This is a type of company that I think of in a lot of ways as a "normal" software company, but is kind of underrepresented in "the literature."

A few things jump out at me.

Most healthy projects do something agile-ish.... The details don’t matter much, so long as you’re talking to each other.

I initially wanted to disagree with this – I think the details matter a lot – but for this audience I think it's probably right.

"The details matter" in the sense that effective teams spend a lot of time sweating the details. Exactly what they do doesn't matter nearly as much as that they're actively examining their processes and making changes to fit. Not only can you not make a team effective by telling them from the outside how to work, doing that is actively counterproductive.

So– there's this contradiction at the heart of the agile. Process matters a lot, and some ways of making software work better than making others. But what matters more than anything else is agency – processes that give people on the team a sense of local control. So attempts to copy effective teams by copying surface-level what they're doing will fail. You'll take a low-agency team that's struggling with one set of practices and turn it into an even lower-agency team struggling with a different set of practices.

The presentation also mentions the team talking a lot – to each other, and to customers.

I think a lot of what makes Extreme Programming "work" is that it's a structured and repeatable way to implement "talk to each other a lot." All production code needs to be built in a pair? You're going to talk a lot.

One of the misconceptions people have about making software is that it's primarily a quiet or solo process. You see this especially in managers who haven't worked on software teams themselves, but a lot of software people have this idea, too. I think a lot of people get into this industry because they want a job with a lot of alone time – I mean, I can see the appeal – and they have a lot of cognitive dissonance that stops them from being able to see that software engineering as an industrial field is very much not that.

The other thing that I think Extreme Programming does is – I think it functions substantially as a way to pull processes that normally happen within an individual up to the team level.

Okay, that's super abstract. What I mean is: Model-building is a big part of software development. Changing software requires building a model, manipulating the model, and then making the changes predicted by that manipulation to the actual code. There's a huge difference between software with a live team that's actively working on it, and software that no longer has a team dedicated to it specifically.

To some degree this has to be an individual activity. The model-building takes place in an individual. But this is risky and choppy. If the person with the model of a particular bit gets sick, progress slows down or stops entirely. It's hard to get redundancy and smooth flow.

So a lot of Extreme Programming practices are attempts to move that model-building process into the team. Pairing means that model-building should always happen in at least two people's heads – no change should ever be known by just one person. Test-driven development builds up a partial cache of the model, and makes it executable by anyone working on the codebase.

Well– sort of succeeded at "short."

As always, happy to get comments/questions/etc. either on the web or as replies to the e-mail.

- Nat