Yellow Squad Weekly Topics: July 13

Summary:

• benji: Juju-based integration tests are a success for incremental value
• bac/gary_poster: Is it ever OK to knowingly check in broken code?
• gary_poster: Not meeting our weekly goals

[introduction] [project report] [tricks] [topics]

benji: Juju-based integration tests are a success for bringing value incrementally

We chose to pursue integration tests of the lpsetup project as a timeboxed, incremental effort to bring value as quickly as possible. As discussed in past posts, we decided to use Juju as our approach to obtaining clean machines in which we can run our system setup script.

benji investigated integration with Python unit tests, but it proved problematic (see the "tricks" post for some of the issues).  He pivoted quickly enough that within a day, we had a script to use to run integration tests on Juju.

It is very simple, basic, and minimal.  We could do much more, and a full "proper" implementation would involve a lot more work.  There are many things to do to improve it--integration with unit tests, test fixtures, and so on.

But we have something in our tree that does the job now.  We can work on the changes later, bringing value incrementally as we have time.  Our next increments will be tarmac integration and more integration test coverage.

We are all very pleased to have this so quickly.  It reinforces our resolve to deliver value and quality as quickly as possible, by identifying the smallest task that can bring value and pursuing it directly, despite reservations--and even expectations--that we might have to rework it in the future.

bac/gary_poster: is it ever OK to knowingly check in broken code?

bac and gary_poster had a kanban card that took longer than a day to complete.  Per our checklists, this triggers a question that we have to answer at the end of the week: why?

bac and gary_poster were working on a refactoring.  They initially tried to be incremental by disabling some tests of code that was about to be significantly refactored, so that they could focus first on the central changes we needed before resolving all the related changes.  They delivered this quickly, but knowingly checked in broken code.

Then, they tried to fix the broken code. They hadn't liked checking in broken code before, so they wanted to check in working code this time...but fixing all of the broken, refactored code ended up taking more than a day.

All that said, at least gary_poster still felt that it was reasonable to have made the incremental check-in that broke code. It moved the central part of the project forward, it kept everyone in sync with the direction of the code and reduced conflicts and rework. The code that was broken was OK to break for a while--it wasn't needed that much yet, and the necessary refactoring was going to be significant.

Is it ever OK to knowingly check in broken code?  What if it is a partial fix of something that is already broken? Why did gary_poster still think it was OK to have broken the code?

We decided that we had done the exact opposite of what we want to do in the future.

• Don't check in code that you know breaks something.
• On the other hand, if you are fixing a pre-existing breakage, checking in incremental improvements is desirable and encouraged.

We resolved gary_poster's feeling with this further observation.

• If you have code that is not essential, and refactoring it is blocking delivering incremental work, consider deleting the non-essential code. If you need to revive it later, we have a revision control system.

gary_poster: Not meeting our weekly goals

We are not meeting our weekly goals. What can we do?

benji: I don't see the goals on the kanban board, so I am not working towards them.
gary_poster: We can highlight cards that are pertinent to our weekly goals by using the high priority markers. They are easily visible, and we have the "Critical" priority for emergencies. ACTION: gary_poster should add these markers. We should do that after each weekly retrospective call.