This is the fourth post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application - this post
• Part V - wrapping up by refactoring the root application

This is the third post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing - this post
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application

This is the second post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit - this post
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application

I have learned so much by following the Koa Js community and framework over the years. My first post on the topic was written in March 2014, when Koa was just a little tiny bird trying out its wings (look up that reference…).

From that point I’ve written many posts, done a few screen casts for fun and other for profit.

4 years (MY GOD!) is a long period but in the JavaScript world it’s eons of time. I noticed that the other day when I refactored one of my later Koa applications into something more modern. I learned so much about the topics that I ran into, while upgrading my code and the resulting code was much more elegant, functional and understandable.

So… I thought I’d do it again. This time you can tag along. This post will be long, but hopefully worth it.

I have a very particular set of memories from my childhood, that revolves around me falling, hitting or otherwise hurting myself. If it was just a bruise my father often said to me:

How bad is it? Is it worth crying for, like you do now?

(I was probably exaggerating quite a lot). Of course, it was!

Tell me, what are you going to do if it really hurts, then?

That was maybe not pedagogically correct for a child in pain but it at least got me thinking. Indeed… what comes after screaming and crying? Could I turn this up? Would it make a difference? Would I get … yes, what was it I wanted, really? Maybe just a hug or comfort. Could I get that by other means of communication that the display I was putting on now?

Of course, 7-year old Marcus didn’t reflect...

Lately, I’ve been deeply immersed in discussions about flow, and I’m continually struck by the myriad benefits that stem from prioritizing better, faster, and smoother flow.

In this post, I’d like to share some recent reflections that have been occupying my thoughts.

I once worked at a large company where they had so many priorities 1 features that they decided to introduce … bam-bam-ba-baaaa … Priority 0. But after a few minutes, we ended up with about 5 items in that category and we realized the ridiculousness of continue to do Priority -1 etc.

Today I saw this pattern in action again, and a new realization about a missed teaching opportunity washed over me. I wanted to share this with you in this post.

Over the last couple of weeks, I’ve been re-discovering an old diagram (more like a sketch really). You can find it scribbled on nearly every whiteboard in our office now because it sparked a lot of interesting discussions on flow, flow efficiency, and optimizations for value delivery.

I wanted to share this with you here, in a few iterations, and also share some of the discussions that it triggered.

First of all, this came up as we had a process that was taking too long. It involved a few people from different departments who needed to complete their work before handing it over to the next department. Then there was a user acceptance testing phase at the end that, of course, took a long time.

The backlog of work was growing much faster than these people were completing work. High stakes, stakeholders, and customers were getting angrier by the minute,...

I often give out a lot of books tips in lectures and workshops, so instead of me typing and find links everywhere, I thought I’d put together a list of them here.

There are only 10, so if one is added another one needs to leave. That said - they are in no particular order.

For each, I’ve given a short little review and comment on why I like the book.

“Wow - this release was awesome. So fast, almost no manual testing and only one bug found in testing,” Sarah exclaimed in joy.

“Yeah, but there was that one bug. It should be zero, huh?”, Marcus responded grumpily from his corner, without looking up from the screen.

“Also - there are still manual testing going on. It should be all automated,” John chimed in, unimpressed.

“Fast and fast … still our build runs in 8 minutes. That is a long time. Way too long if you ask me!” Alex sighed as she pointed to the build log on the screen.

Sarah went back to her desk. Her enthusiasm was gone.

I think we often miss the improvements we made by not looking back and appreciate the journey we made. If we only talk about what is still not great we lose track of how far we have come. This is...