Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Thursday, March 25, 2021

One person per task

One of the least teamy things I see with software teams is limiting the maximum and minimum number of items of work in process – tasks, stories, whatever you call them – both to the number of developers on the team. For some reason it’s always the number of devs, never the number of product owners, customers, QAs, or deployment people. Got four devs? Then there should be four tasks in process!

This approach is surprisingly backward given that we’re all supposed to have come so far as the leaders of the Agile Fourth Industrial Revolution 2.0 that we’ve internalised and transcended Goldratt’s theory of constraints. It’s the last holdout of the old Taylorian school of management. Everybody is working full-tilt, so if anyone runs into any trouble then everybody else is too busy to help them. If what they’re doing is upstream of anybody else’s work, then they are going to be blocked too, but rather than fix the blockage they’ll pull another task because one-person-per-task at all times!

So much is this at the core of software team thinking that when I’ve suggested in informal discussions that maybe we should do something else, people are confused. Are you saying that we should have a developer who isn’t assigned to a task, just in case? What does that person do the rest of the time, play Minesweeper? As if the only alternative to “one person per task” is “one person per task but perhaps there is another person”.

One person per task has the “nobody can help” disadvantage already mentioned. In fact, people are disincentivised from helping, because their task has their name on it and your task has your name on it. Did issue #1348 miss the release train? Bob is such a drag on the team, at least Karen managed to ace her ticket. Maybe we should reevaluate who leads on the next project.

You’ll see other effects of one person per task. Code reviews fall into one of two categories: “LGTM” and “axe to grind”. Only the people who are really invested in making sure that nobody ever misses off a const keyword, or uses function() where => would suffice, will take the time to commit to code reviews. Everybody else will skim-read, look at the CI output to see if the tests pass, and get back to their own task with their own name on it as quickly as possible. This loses both the review benefit of code review, and the shared-understanding-of-the-code benefit too. Everyone only really understands the features they worked on individually, there just happens to be a big ball of those features in one repo.

Code quality suffers. Each individual is too busy chopping down trees to sharpen the saw, because there’s always a next task for each developer to do.

Everybody else has been under-resourced. We need one developer per task, because what I can see is features in a UI and the only people shovelling features are the devs. QA is a cost centre, so if we can get one QA (or at most, one per team) then let’s do that. Same with ops. Infosec, coaching, UX, and other nice-to-haves can be consultants as needed. Weird how our devs are ticking off tasks like billy-O, and nothing’s getting through to release!

The alternative to “one person per task” is not “one person per task and some change”. It’s “one objective per team”. Set the goal, and let people work out what to do about it and how everyone contributes. As they used to say, “give them the environment and support they need, and trust them to get the job done”.

posted by Graham at 22:46  

Sunday, March 7, 2021

The Vizzini Effect

A bunch of the topics I wanted to discuss all turned out to have a common basis, so I’m going to write the post about the commonality using a couple of examples from the specific topics for illumination. Maybe I’ll come back to those topics in more depth later, each one is itself interesting and valuable.

The common thing is the Vizzini Effect, named after the Sicilian in the Princess Bride. In the movie/book, Vizzini often describes events as “inconceivable,” to which Inigo Montoya replies “you keep using that word. I do not think it means what you think it means”. The Vizzini Effect in software engineering (and undoubtedly in other fields of endeavour too, I doubt we’re special) is when the same thing happens: a word or phrase seems to adopt a different meaning such that two different people, or two different groups of people, can mean it to use different things without either seeming malicious or disingenuous. In the examples I’m going to explore here, those groups are separated by time rather than space. But unlike with Vizzini, it’s not that one person is using a word in a weird way, but that collectively software engineers seem to have decided it takes a different meaning.

Examples of Vizzini Phrases

Object-Oriented Programming

OOP is perhaps the ur-example here, and definitely the one with the most obvious dog-whistle. “I invented the term Object-Oriented Programming,” says Alan Kay, “and I can tell you I did not have C++ in mind”. To Alan and that early group of Smalltalk programmers at Xerox, ParcPlace, Tektronix etc., object-oriented programming was extreme late binding and decoupling through message sending. These days, it is often programming in any language that has a “class” keyword, or a straw man meaning any form of mutable state.

Agile

In the discussion do you think Agile/Scrum is beneficial for software delivery?, the first answer (at time of writing) says “The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship.” The question asks about the surprising rituals and the extra layers of bureaucracy. That’s the opposite impression than the one I have, where pre-existing software engineering methods tried to minimise or even automate away the programmer contributions. The lightweight methods, promoted by (among others) the agile alliance, sought to build projects around motivated individuals, giving the support they needed but leaving them alone to get the job done. The alliance members thought that the best architectures and designs were created by self-organising teams: a far cry from imposing methodologies to remove power from technical contributors.

Design Patterns

Design Patterns in software used to refer to the Christopher Alexander idea of identifying repeating problems in architecture and building a shared language that succinctly communicates understanding of the problem, solutions selected, and trade-offs in those solutions. These days it seems to mean any of the examples of design patterns in the Gang of Four book on early-OOP implementation patterns, and no others.

Free Software

The Free Software Foundation and the GNU project were created with the goal of extending desirable human rights and liberties to the world of computing. These days it seems to mean “open source, but said by a person who uses the word actually a lot”.

Open Source

The Open Source Initiative was created to generalise the Debian Free Software Guidelines out from the Debian project to general business rules for software, based on the prior successful Open Systems movement and the liberties identified in the Free Software Movement. These days it pretty much means making the components needed to build SaaS subscription products available at zero cost.

Software Engineering

In 1967, software engineering was a provocative term, meant to imply that the art of creating software would be somewhat improved if it had a socio-scientific basis. These days software engineering is two words anyone who gets or wants to get paid for programming uses on their CV/résumé.

What happened?

My impression is that three things changed, and that two of them are almost the same. The origins of all of these phrases are in particular times in history, made by particular people, talking in specific contexts. Time has changed, which has changed the context (or at least the relevance of the original context), the people who said the things have changed, and so many new people have entered the field that a majority of practitioners no longer know who the original people were, nor have experienced the context in which they spoke.

It’s entirely possible, for example, that the agile methodologies which were lightweight reactions to software engineering around 2000 are oppressively bureaucratic in 2021. We expect to be able to release software multiple times per day now, using analytics and telemetry to understand in real time how it’s being used. The agile folks wanted us to release up to every two weeks and to talk to someone before doing it, ugh!

Some people talk about an Agile-Indu$trial Complex, suggesting that there’s some shady cabal of consultants and certification bodies conspiring to make us all agile so they can profit from it. Again, maybe true. Others talk of companies who “talk the talk without walking the walk”: they got the consultant in, decided which parts of this whole Agile thing sounded nice or relevant, and adopted those things then trumpeted their “fully agile workflow” on their websitesfax banners.

And, of course, there’s the telephone game. Even those of us who heard about it from the horse’s mouth—maybe worked on an XP team, or read “Free Software, Free Society”—will have learned a slightly different thing than what the originators were trying to teach us, or thought they were teaching us. When telling others, we’ll have misremembered, and adapted, and extemporised. And so will the people who learned from us, and so on.

The telephone game is subject not only to slow evolution, but to a Byzantine Generals attack. If someone wants, for example, OOP to die so that their preferred paradigm get used instead, they can inject a false message into the call graph. This is where Vizzini meets Lewis Carroll’s Humpty-Dumpty: I keep using this word, and I do not think it means what you think it means.

Take into account the fact that most people who work in software now didn’t work in software five years ago, and that this was true five years ago and so on, and you realise that the vast majority of people will have learned about any “classic” idea in software from a telephone conversation.

What to do?

Well, the first question to answer is, does anything particularly need to be done? Maybe these are ideas that have had their time, and can just fizzle out. But evidently for all of the examples above enough people want the ideas to continue that they (well, we obviously) keep trying to dredge the original discussions out of the history books and put them back into contemporary discourse. To do this, they need recontextualising. For example, nobody cares that Richard Stallman couldn’t get a printer driver in the 1970s, but maybe they do care that there are things that they aren’t allowed to do with the smartphones they think they paid for. That’s how ideas of software freedom could be reintroduced.

Maybe the original phrase has become toxic and needs to be retired, without the original meaning being lost too. That is, whether you like it or not, the reason that “Open Source” was created as a term: to remove deliberate and accidental confusion over the word “freedom” in a business context, and to provide familiarity to people who had already adopted Open Systems ideas. It’s why Devops exists: to tell the stories of Agile again, but to those who didn’t listen the first time, or who listened and heard the wrong thing.

The telephone game can’t be avoided. You have to keep telling the stories if you want new people to hear them, and that means accepting alterations in their re-telling. And you need there to be more than one raconteur, even if they’re telling slightly different versions of the story. Don’t count messiahs, count prophets. Only don’t count prophets, count gospels. Only don’t count gospels, count churches. Only don’t count churches, count preachers.

You’re never going to get every programmer or software professional in the world to agree with your interpretation of some phrase. But you can use contextually-relevant stories to tell people things that might help them make better software, and you can follow up “I do not think that means what you think it means” with a conversation in which you both learn something. Maybe it’s your understanding that’s wrong?

Inconceivable!

P.S.

I do a lot of writing, podcasting, presenting, and streaming about how to make software. Most of it has been free, still is free, and I don’t intend to change that. It’d be great if you are able and willing, for you to support that free work by becoming a patron. No obligation!

posted by Graham at 20:31  

Powered by WordPress