Yellow Squad Weekly Topics: August 10

Summary:

• gary_poster: reconciling staff unavailability with kanban work-in-progress (WIP) limits
• gary_poster: OO versus functions, inversion of control, and how much agreement is important
• gary_poster: More incremental success with our integration tests

[introduction] [project report] (no tricks this week) [topics]

gary_poster: reconciling staff unavailability with kanban work-in-progress (WIP) limits

We find Kanban WIP limits to be helpful in our squad for many reasons. They keep us focused on completing work; they encourage us to collaborate; and they encourage us to have slack time, doing extra work that helps Canonical and ourselves.

In general, on our five person squad when it is working at capacity, we like to have the WIP limit at three for our active coding and review cards. This reflects the fact that gary_poster is often only half available, given management responsibilities; and the fact that we want to encourage collaboration and slack.

This rate often works well, and has the effects that we are looking for.

However, we frequently are not working at full capacity. Someone is on-call reviewer for the day. Someone is on vacation. Someone is involved with non-coding tasks, such as the interviewing that we are doing now.

How should this affect our WIP limits? We want to encourage collaboration and slack all the time, not just when we are working to capacity.

We discussed this over the course of two meetings, and settled on trying out a couple of simple guidelines.

• If someone is only unavailable for a day or two, they should make a card that represents their unavailability and park it in the "coding" lane. This will use up one of the WIP limit spaces. They should delete the card once they are available again.
• If someone is gone longer, they should reduce the WIP limits for the pertinent parts of the board. To facilitate this, we make sure that everyone who uses the board has full "Manager" privileges.

We discussed using existing in-progress active cards to hold the spot for the unavailable team member. That is problematic because it causes long cycle times. A temporary placeholder card or a reduction in WIP limits represents our goals better.

gary_poster: OO versus functions, inversion of control, and how much agreement is important

Some of the squad have, to varying degrees, become more aware of their dissatisfaction with the complexity that often evolves from object oriented (OO) programming. Deep and multiple inheritance are example culprits, with the associated "ping pong" of methods that have subclass methods calling superclass methods, which then call other methods that may or may not have been overridden.

On the other hand, discarding OO can lead to arguably reinventing it within closures, or violating DRY. Moreover, idiomatic Python programming typically emphasizes the OO paradigm. Procedural Python has been refactored to OOP within the Launchpad team more than once. Functional programming is somewhat supported in Python (look at the new immutable/persistent data structures!) but its use is virtually nonexistent in our team, and elements that are often considered important to functional programming such as tail call optimization are missing from the language.

How can we resolve this?

Similarly, and relatedly, we have discussed inversion of control. Some of us have expressed concerns with it, as a subset of a concern with frameworks generally. Others of us point out that inversion of control is arguably a part of other ideas that have a better reputation than frameworks, such as declarative programming, and some kinds of configuration. Moreover, many frameworks themselves are huge success stories, and dismissing them out of hand seems problematic.

How much do we need to agree?

gary_poster wants to bring up these disagreements hopefully to reduce rework and to reduce underlying friction. Admittedly, the friction has not been too much so far, but we do have historical instances of rework.

Since gary_poster's goal is to reduce rework and reduce underlying friction, simply agreeing on a compromise might be sufficient. We also discussed increasing our use of pre-implementation calls in order to encourage building shared approaches, but many of us were concerned that pre-implementation is too early in the development process to pursue this goal.

We discussed. We don't have an answer yet, but we are working on it. So far, I think we can agree that both OO programming and inversion of control should be used carefully, thoughtfully, and perhaps even sparingly. We also agree about some of the dangers of OO programming. We'll be exploring this more in the future.

One thought is that writing in Go should make some of these discussions go away! That's not a sufficient resolution, though.

gary_poster: More incremental success with our integration tests

We reiterated our happiness about the incremental approach we took to the lpsetup integration tests. We've taken it further. As mentioned in the project report, we now have a powerful set of automated checks using some sophisticated technologies. All along the way, it was bringing us value. It could be taken further, but if we stop now, we're pretty happy with it. This is the way we want to work generally.