Pycon NL: workshop: measuring and elevating quality in engineering practice - Daniele Procida¶

Tags: python, pycon, django

(One of my summaries of the Pycon NL one-day conference in Utrecht, NL).

Daniele works as director of engineering at Canonical (the company behind Ubuntu). What he wants to talk about today is how to define, measure and elevate engineering quality at scale. That’s his job. He needs to influence/change that in an organization with a thousand technical people in dozens of teams with 100+ projects. They ideally must converge on the standards of quality he has defined and there’s only one of me. Engineering people are opinionated people :-)

Your personal charm and charisma wears thin after a while: there needs to be a different way. So: how can you get 1000+ to do what you want, the way you want. Ideally somewhat willingly? You cannot make people do it. You’ll have to be really enthousiastic about it.

He suggests three things:

• Principle. Description of quality as objective conditions, allowing it to be defined and measured.

• Tool. A simple dashboard, that reinforces your vision of quality and reflects it back to your teams. Daniele focuses on documentation, and showed a dashboard/spreadsheet that showed the documentation status/progress of various projects. You can do the same for “security” for instance.

• Method. A way of drawing your teams into your vision, so that they actively want to participate in.

It being a workshop, we worked through a few examples. Someone mentioned “improved test coverage in our software”.

• Describe your aim(s). What do you want. What is the background documentation. What is your reason.

• You need objectives on various levels. “Started”, “first results”, “mature”. And you can have those levels for each of your aims/categories. Start small and start specific.

  • Started. “The team understands the significance of automated testing”. “We have coverage information about tests”.

  • First results. “There is a significant increase in test coverage”. Note: “significant” means you have something to talk about. You can be reasonable on the one hand, but you can also call out low numbers. Human-sized words with value, like “significant”, help internalize it. More than a number like “25%” would ever do. You don’t want to check off the box “25%”, you want to be able to claim that your team now has significant test coverage!

  • Mature. Let’s keep it simple with “100% test coverage”.

• Measure the level projects are at at the moment. Show it in a dashboard. He used a Google spreadsheet previously, now it is a Django website. He’ll make it a world-public website soon. So it is visible for everybody. This helps draw teams into it.

Why does this work with human beings?

• Peer pressure. People see their peers doing the right thing. People want to be seen doing the right thing.

• Objectification. The contract and the results are described objectively. The conditions and evidence stand outside you: it is not personal anymore, so it is not a threat.

Humans are funny creatures. As soon as they believe in something, it will carry them over many bumps in the road.

People love to see their work recognized. So if you maintain a spreadsheet with all the projects’ results and progress, you won’t have to ask them for an update: they will bug you if the spreadsheet hasn’t been updated in a while. They really want to see the work they’ve put in!

You can get a positive feedback loop. If the work you need to do is clear, if the value is clear and if there is recognition, you’ll want to do it almost automatically. And if you do it, you mention it in presentations and discussions with others. Then the others are automatically more motivated to work on it, too.

Giving kids a sticker when they do something successfully really helps. It also works for hard-core programmers and team managers!

Unrelated photo from our 2025 holiday in Austria: just over the border in Germany, Passau has a nice cathedral.