I’ve been playing around with refactoring a Koa application to use modern JavaScript constructs like async, await => and do away with generators etc.

In doing so I had an epic battle with mocha, monk and supertest to use async / await etc. I finally found a good structure for this purpose that I wanted to share.

This is the fifth and last 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
• Part V - wrapping up by refactoring the root application - this post

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,...