Evan J Palmer's Blog

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

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

Using a sys_refcursor Output Parameter from a Oracle Stored Procedure

In your SQL IDE, such as PL SQL Developer it’s not entirely straight forward to access the results of an Oracle stored procedure, when the results are returned via an output parameter of type sys_refcursor.

In short, here’s the code:

l_rc sys_refcursor;
l_rec my_rules%rowtype;
mypackage."MyProcName"( l_rc );
FETCH l_rc INTO l_rec;

dbms_output.put_line( l_rec.field_one || ' ' || l_rec.field_two );

CLOSE l_rc;

An explanation:

Firstly we need to declare some variables to use. l_rc is a cursor that we will pass to the procedure, to store the output results.
l_rec is a record into which we’ll store each iteration of the cursor.

After the declaration we execute the package, populating the cursor.

We then loop over the cursor, storing the value in to record, or row, that we declared above, ending when the cursor is empty.

Remember to close the cursor to release the context area in memory.

Thank you to Justin on StackOverflow for answering my question.

As an aside, moving from SQL Server to Oracle has been interesting. I’ve found several commands or concepts that are trivial in SQL Server to be a little challenging in Oracle.

  • No auto increment for primary keys (before version 12) have to use triggers instead
  • The concept of Packages, with a public spec and a private body
  • We don’t have to tell parameters how long their nvarchar2 is, but we do in the table (this is cool logically, but feels inconsistent)
  • The concept of the ORA file

Respect For Women Characters


A group of women players I jam with were given the suggestion “rock band” in the last class.  They decided to do the role of band members as men.

In another scene, a married couple are having dinner of an evening and discussing their days. The male is a judge and the woman stays home and looks after the kids.

Later, a drunk piano player’s wife enters the room and is immediately endowed with the characteristics of being a floozy and prostitute.

When improvising I do think it’s important to play to characteristics and to recognize archetypes, but I’ve noticed that women are given derogatory or subordinate, low status roles  more often than not. Or, when choosing
a certain type of character, such as a lawyer or a baseball coach, they will choose to play it as a man.

Why couldn’t the band members be women? Why was the male a judge and the woman a stay-at-home mum? Why was the woman in the scene automatically a floozy?

Now, the people in my class are not sexist, and would never speak or act in a derogatory way towards women in real life. And it’s worth noting these character choices were made by both the guys and girls in the class. But I do think there’s an underlying lack of respect for women characters in general in my local improv scene.

There are two reasons why this should change.

Firstly, not respecting women characters reinforces stereo types in real life. Why propagate a shitty stereotype?

Secondly, the scenes will be more interesting without leaning on that predictable flow. Breaking that mold would likely result in cooler scenes and characters with more depth.

I think it’s worth keeping in mind.

Thanks to my awesome teacher, Pete Lead for bringing this to my attention.


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.

Fixing Focus in Post with Adobe Premiere

I’m not a very good film maker… yet.

I’m bad.

I went out to shoot with some friends – sixteen hours away by car – and when I reviewed the footage at home (yes, I waited until I got home to review) I found that one of my main shots was not in focus like I had expected.

I’m sure there are lots of other things wrong with the shot, but hey, it’s all learning!

Anyway Here’s the original shot (poke the image with your mouse to upsize):
Without Sharpen

You can see the actor’s melon, in particular his hair, is not in focus at all. Check out his poorly focused shoes too. I was bummed but luckily a friend of mine told me to try the “Sharpen Tool” in Premiere.

I was sure this wouldn’t work, because I mean, if the information isn’t there, it’s just not frikken there. We can’t fix it in post. I mean, that’s like in CSI when they zoom in on a blurry face on a security camera and all of a sudden we can see the mole on the murderer’s right cheek aaaaaaaaaaand he’s guilty! Welll…IT DOESN’T WORK LIKE THAT!!! Right!

… right?

Luckily I’m a big dummy, and it does work like that.

Here is the same frame with the sharpen applied (click for embiggification):

With Sharpen

Note the actors shoes and shoe laces, and his hair. Not perfect, but good enough for an amateur, like me.

Now I know why Adobe’s slogan is “Making Dreams Come True”…. at least that should be their slogan.

For more information on using the sharpen tool, give this a click!

Logging into Visual Studio 2013 – forms done wrong

So I thought I’d have a bit of a play with Visual Studio 2013.

Here’s my experience

I download, install and, run.

It prompts me with a login screen. Hmmm.. I’m not a member… that’s cool I’ll sign up. *click*

Now I fill out a long scrolling form and fill out the captcha *click*.

ERROR! Ah, I forgot to put in my post code because hardly any of the form fits in the miniature space they’ve allowed.

That’s cool… filling it in… *click*.

ERROR! Oh, they cleared out my CAPCHA… okay, filling that back in. *click*

ERROR: did I get that wrong? was that ‘p’ or a ‘b’? That ‘j’ kinda looks like an ‘s’. I’ll try the audio version *click*.

Listening… nope that. Doesn’t make sense to me. back to the written version *click*

ERROR! Ooh, I got the CAPCHA right! (Wooott!) but my email address is already registered. Thanks Microsoft, you could have told me earlier. Oh well that’s cool. Back to the log in screen. *click*

Filling in my details… guess my password *click*

ERROR! I guessed wrong. Well I’ve been trying to use different passwords for different sites for a while now. So that’s not surprising. I’ll just click the reset password button *cliiii…… nope that button doesn’t exist.

Okay… I pull up Chrome and go to the MS site. And am logging in automatically.

Okay. So I log out, try to log back in again, and FIND THE RESET PASSWORD BUTTON!

And it’s smooth sailing from here.

What I think, in order of importance:

1) Make the form smaller. Is that really the minimum amount of info needed?
2) Have a reset password link on or near the error
3) Asynchronously check my user id as I’m filling out the massive form
4) Make better CAPCHAs. Surely we have a better alternative… ?
5) Make it more obvious that the log in optional ? I just ran through the process again, and noticed a small “skip” link under the sign in button on the first screen. That’s cool, but there’s no skip button on any subsequent screens.

Popcorn Time – Awesome Illegal Netflix/Plex Alternative



If you’re familiar with Netflix, or Plex, or XBMC, you’ll get a kick out of Popcorn Time. It’s this great program that acts like a slick media player with a basically complete library, but instead of hooking into a legitimate library (like Netflix) or your local files (like Plex/XBMC) it STREAMS TORRENT FILES! …hence the illegality.

Well, I guess it’s illegal… if the country you live honours American copyright law… and only if you choose to download content that is under copyright (there’s a lot of public domain stuff out there too).

But whatever. I love this thing  – even though it’s not finished yet (IMO… and it’s in beta). They still need to get the search a bit better, give us some preferences around quality and, make some kind of offline mode (so we can choose some poor-health-torrent flicks to download now, and watch them when we get home).

I’d also love to see offline mode integrated with tablets and phone devices, like Plex does.

Having said all that, this is such a massive awesome step in the right direction, I’m very excited about the future.

One other interesting thing to note is it’s lack of adverts in the app. If there are no adverts to pay the pirateers, and the movies aren’t being paid for by subscribers or movie-goers… I guess no one makes money. Not a problem, since the share of Popcorn Time users is basically nil at the moment, but interesting none-the-less.

Ideally, I’d love to see something like this take off, where the movie industry can still make some money and keep making stuff I love – HAVE THE SCIENTIST WORKING ON THAT IMMEDIATELY!


Justin Beiber and Online Bullying.


Recently Charlotte Dawson committed suicide and people on talks shows have started talking about bullying again, in particular online bullying.

Perhaps that’s one good thing to come out of the tragedy.

I think we can all agree that bullying is shit. It does no good and can end terribly with self destruction and suicide, or violence against other people.

Why do we turn a blind eye to the massive unrelenting bullying to which Justin Bieber is subjected?

Recently, over a quarter of a million people signed an online petition to deport Justin Bieber. In another bullying incident a bill board was erected placing a bet on on hockey game between Canada and the USA,  loser keeps Beiber.

It’s like bullying on steroids.

And as usual, the people who are doing the bullying think this is funny –  I can only assume that Bieber feels the same as any other human being that gets bullied.

I’d just like to point out that what people, the media, are doing to Bieber is on a much larger scale than what happened to Dawson… I certainly hope it doesn’t end the same way.

…I mean, he’s a fucking kid.

Agile Techniques and Developer Stress

Homer: [to staff] Are you guys working?
Man 1: Yes, sir, Mr. Simpson.
Homer: Could you, um… work any harder than this?
Man 2: Sure thing, boss. [they do]
Homer: Hey, call me Homer.

I’m an advocate of Agile Methodologies, but it’s recently been brought to my attention that there is a potential downside. When this downside manifests, good developers can feel over worked, over pressured, and burnt out.

In this article I’ll give a brief outline of the problem in each situation, followed by how it could possibly be remedied.

The first case that was brought to my attention when I was was chatting to a new colleague of mine, I’ll call him Jimmy Lazerface (or JL for short). We were talking tech and he had been super enthusiastic about everything. Then I moved onto Agile – I was acting like a total Agile Fan Boy. I noticed he quieted up. Once I pressed him for details it turned out that the last job he’d had, indeed the place he’d worked only a few weeks earlier, had implemented their version of Agile, and he had had a bad experience. The Scrum Master/Tech Lead was giving very tight estimations on work and holding the developers to those deadlines – ensuring that the velocity stayed where he thought it should be.

I think there are a few parts to a solution here. Firstly, the developers should be involved in the estimation process, not just one person. Using a technique like Poker and T-shirt sizing, we can get a better, fairer, idea of how much work can be achieved.

Next, I think trying to maintain a velocity is a bad idea. Velocities should be used to help estimate. If there is a big drop, can it be explained in the retrospective? Or does your velocity need to be adjusted?

Finally, I think some responsibility can be put on the scrum master/tech lead for not not having some faith in his team (JL is one of the most switched on developers I’ve met, so I know he wouldn’t be slacking off).

The next example I came across of Agile being viewed in a less-than-positive-light was today. An older colleague of mine known as Professor Donaltron (or PD), was discussing the shift over the last few years to agile from a more waterfall/BDUF. He told me, That in the waterfall days, a project might last six months. The first month or so would be design, the next, say four, would be writing up functionality (i.e. actual coding) followed by a month of testing. The way he viewed this cycle was the work ramping up at the beginning, then ramping down at the end. He felt that with agile, his whole work-life was a busy period – no down time. Poor PD. It was obvious that he was feeling burnt out, and as a close colleague of mine I know he has been working really bloody hard.

Seeing as how I work with PD now, I have an insight that might point us in the direction of why he feels this way. I know PDs team do not use retrospectives or do much estimation. They are almost entirely R&D so instead they kind of pile on stories and move them across the agile board once they’re “completed” (which in itself is often hard to define. Everyday they have stand ups, where they have to explain what they did the day before. One card might could be XL (or more) and take a developer longer than a sprint to do. This whole time it could be perceived that PD is not making much progress, despite the fact that he could have put an enormous amount of effort in.

Since PDs team is R&D estimation is very difficult and rarely happens. In the same vein, it’s difficult for the Scrum Master/Stakeholder’s to understand how much progress was made.

I think in this case PD has to do a better job of communicating what he has done in the stand up. I actually advocate him adding new stories to the board (or sub tasks perhaps) so that there’s a visual representation of what he’s doing as movement across the board. This should then be discussed in the retrospective. This may sound like a break from agile, but I believe that agile implementations should be just that – agile. Teams should select the most useful parts of the methodology and apply that. In this particular R&D team, cannot apply many of the cool agile techniques we know and love, so must adpot a subset, coupled with anything that works for them. As long as there’s communication, openness and iteration, I can dig it.

My own experience of Agile has been overly positive, however upon reflection, I remembered when I was first introduced to daily stand ups. At the time I had been at this particualr company for a year or so, so my responsibilities included my project work, AND daily support-style work for stake holders. I remember that I wasn’t used to having to account for my time every day, so as a result I’d get to the daily stand up and have trouble talking about why I hadn’t made as much process as was expected.

The solution here is was, once I realised the problem, was to keep track of any bespoke support I’d done the day before and talk about it in the stand up. Then in the retrospective I would collate what I’d done and show that it was a meaningful amount of work. From here we started putting effort numbers on support work (kind of reverse estimation) so we could work out a kind of velocity separate to the usual project work. We then created a support roster to share the support work, and tried to focus on getting the “support velociy” down. It was a successful way to tackle that problem.

In conclusion, I think developer burn out is a worthwhile thing to note when employing agile techniques. Perhaps more emphasis should be placed on asking how developers feel during the retrospective? Did they work too hard? Not hard enough?