Evan J Palmer's Blog

A blog about learning (code, improv, film and, anything else).

Category: Uncategorized

The Reason for Principles


Recently I discovered the benefit of writing up architectural principles. Not a new concept, but one that I had not previously done.



The Looper Card

The Problem

We’re working in an agile environment and have a bunch of tech debt that is hard to size and prioritise against functional deliverables. How do we make progress improving the tech debt?

The Solution

The Looper Card loops around, sprint after sprint, chipping away at a problem until we decide we’re done. It’s time boxed, so the points always count to our velocity, even if nothing is technically released into production (because we still learnt something).

It’s done when we say it’s done, and we use it to tackle the next problem.


Problem areas that are good candidates for The Looper Card are problems that might have some of the following traits:

  1. Are hard to size – how long is a piece of string?
  2. Are potentially endless – everything can always be made “better”
  3. Can be tackled in small increments
  4. Don’t have obvious benefit to the customer, so probably wouldn’t get prioritised against other work

The Process

Effort on The Looper Card should be time boxed to 1 day.

Loop to start?

Pick a topic.

In Sprint Planning the scrum team picks an area that needs improvement, that fits the criteria for the looper card. We define a very loose goal.
2 Put The Looper Card in the backlog for the sprint.

Move the card to In Dev – try to raise a PR in a day.

 At some point in the sprint, a dev picks up the card and attempts to make a committed change – raise a PR. The idea is to do a little analysis, and make a real change. It doesn’t have to be the best change, just an improvement of some type.

The idea is not to do a spike, and plan for other iterations. Lots of the analysis and learning comes from jumping in and trying to fix it. Even if you’re not successful this time, next time you will have a better idea.

4 Follow the normal stages of a sprint, through review and test to done.

If at any point in process, the task exceeds one day, stop what you’re doing and put the task back, ready to be placed in the backlog for next sprint.

5 The code will be released as usual in the next release!


In code, the process would look like this loop:

looperCard.timeBoxLengthInDays = 1;
    if(looperCard.topic === undefined)
        looperCard.topic = sprintPlanning.selectTopic();
            case IN_DEV :
            case IN_REVIEW :
            case IN_TEST :
        looperCard.topic = undefined;

Potential Uses

  • Log Clean Up
  • Unit Test Clean Up
  • Any automation
  • Improve swagger
  • Write some annoying (but useful) documentation


Here’s a slide you can use to present this idea to the team: The Looper Card

Pretend Like You’re Interested.


I’ve recently been giving series of presentations to large(ish) groups at work. In my opinion they’re good presentations, and I’ve received some great feedback.

While I was giving the presentations I noticed a few different categories of body language given by attendees in the room – there seems to be a spectrum of visual attentiveness.

Some people looked directly at me, and nodded as I made points, leaning forward on their chairs attentively while I explained finer points in detail with a diagram.

Other people looked mostly at the slides, even though there isn’t a massive amount of info on there – maybe a few word or an image. They tended to have a fixed focused on the projection, rarely looking at me.

There was also a third type of attendee who seem disinterested and was on their phone or looking out the window for whatever reason.

I have a few points I’d like to make about this.

Firstly, I was initially disheartened and put off by the latter type. Why weren’t they interested in my awesome presentation? Am I doing it wrong? Am I not speaking clearly? Is my subject complete and utter crap? Have they realised I’m actually just a big phony?

No, I don’t think so. There are probably lots of reasons these people were looking disinterested. Maybe they’re super familiar with the topic already? Maybe they were deep in a debugging session before the meeting, and haven’t fully context switched yet? Maybe they have something on their minds from out of work? Or perhaps that’s just how they listen and learn? For whatever reason, I think it’s important not to be distracted and dejected when presenting to people with this sort of body language – which was my initial reaction. 

Secondly, the people who stared at the slides throughout the presentation. These people were fairly easy to present to. They didn’t give me much feedback, but I felt as if they were letting the information sink in, and it was easy to roll through the motions and get the content out to them.

Thirdly, the more active attendees. The people who looked at me, and nodded. The people who smiled when I made a light remark. The people taking notes. Thank you! Having some feedback or recognition really helped me. When I wasn’t sure if I had explained myself well seeing these people jotting things down in there notpads/laptops confirmed that I was on the right track. I think the more people who were like this in the room, the better my presentation went.

In conclusion, if you’re attending a presentation perhaps it’s worth considering how you present yourself. Show some interest and that enthusiasm may be fed back to you! If you’re the one doing the presentation, my advice is to be ready to expect different types of body language and don’t be too disheartened by blank faces.