marcusoft.net - sharing is learning


function share(knowledge){ return share(++knowledge) }

CoffeeScript - what I've should have done


The blog post I wrote yesterday was from my experience at the time. I even ended the post with a callout for better ways.

And sure enough, twitter to the recscue:

As a side, this why I hang out on twitter. There are brilliant people there that will push you towards ever better. Thanks Erwin for this.

So… what does that mean for my post yesterday… Let’s find out:

Read on ...

Get started writing NodeJs with CoffeeScript - not a piece of cake


For some reason I’m from time to time drawn to different languages that compiles to JavaScript. And then I’m drawn away again. Especially nowadays with ES6 coming up many ideas and needs for CoffeeScript or TypeScript goes away.

So the other day I found myself thinking again:

Hey - CoffeeScript. That's not such a bad idea. Maybe I should try to write some.

CoffeeScript and I have a dormant but warm relationship because this little language was the one that helped me understand not only JavaScript but also got grips of functional programming.

I thought I’d write a simple little kata in Node to fresh up my CoffeeScript-fu. How hard could it be?

Well… there’s quite a lot of setup and idiosyncrasies that you need to be aware of. This post tries to summary what I learned as I got my environment up and running. Specifically; initialization, run tests, write code and run my app.

Read on ...

What if money was not an issue?


In Indonesia there’s an interesting development going on right now in health care. A nationwide health insurance is being rolled out. For everyone. Until now health care has been paid for privately or via private health insurances, but with the advent of BPJS (that it’s called) everyone can now afford to go to the hospital… or at least there’s fixed tariffs.

Before we continue, imagine the effort to roll this out in the world 5th biggest population… 250-270 million people. Most of which is very poor. I think this is such a great thing and I applaud the Indonesian government for doing it.

However… I work for hospitals in Indonesia. On the “other” side of things. For us this is also an opportunity since this will bring more patients to our hospitals and we get to serve those in need. But there’s another side of the story that have very interesting implications around service quality, of all things.

In this post I will tell you a little about that, quote a great book and then ask myself some tricky questions that I cannot answer. It will be a blast - tag along!

Read on ...

Config handling in Node and Heroku - with secrets


Once you’ve coded and tested a Node application we are anxious to deploy it and put in front of real users. I’ve blogged before on how you can do that very easily and fast with Heroku.

But one thing that trips me up a lot is the configuration and especially things that I want to vary per environment, like connection strings to databases or user names. Hey - some of those things I don’t even wanna check into source control at all. They might be secrets that I don’t want anyone else to get hold off.

In this post I’ll show you a little function / object that I’ve found plenty use of and that I now include in almost every project I deploy. I’ll finish up with a little discussion on how to handle secrets too.

Read on ...

All the great teams


I reflected a little bit about the great teams I’ve had the honor to be part of. It’s just a few out of all the teams that I’ve been part of that I would call great. But they all shared some common traits.

My first ever scrum team was a great team, that I still think back on fondly. Gothenburg Brass Band was an orchestra that I had the opportunity to be part of for almost 2 years - total awesomeness. My “current” (since I don’t play with them now) band Vasa Band is another group that I hail as a great team. The prayer group we had 2006-2010 in our home was an amazing group too.

Looking back I remember these things that was common about them, in the very particular order that I remember the traits…:

Read on ...

How far have we come?


A few days back I said something to my client that apparently many people on twitter found interesting.

My client, the hospital that I’ve written about many times before, has a big project ahead. We are going to be accredited for quality in all our processes. So… there’s a lot of documentation, implementation and training to be done.

Nobody really knows how much. We think, for hearing other projects, that it’s about 6 months and made that our goal. But we haven’t got a clue how much work it is left for us.

The work is divided into 4 areas that we’ve formed teams around. Each of this area has a number of targets that they need to consider and help the hospital to meet.

So I asked them:

How far have we come?
Read on ...

Review: Cucumber for Java


Imagine that you want to learn a new technology or tool. Who would you want to learn that from, and how? For me I’d want to sit down and pair program with the creator (not The Creator, but you get what I mean) of the tool, and then someone who has vast experience implementing this and finally someone who knows this tool well on my platform. Preferable all three together.

This book is exactly that. It’s an opportunity for you to learn Cucumber from Aslak Hellesøy (the creator of cucumber), Matt Wynne that has consulted and trained on the tool for a long time and Seb Rose that have build the Java Implementation.

Now, the important thing to remember about Cucumber is that it’s not about the tool. Specification by example (BDD) is first and foremost a communication and collaboration technique that doesn’t really need a tool. I’ve got a lot out of just “specifying with examples”. But soon you want to verify your specifications and then Cucumber is great choice.

The author stresses this point throughout the book and make the reasons for Cucumber and human-readable tests (as opposed to JUnit test) very clear.

The books consists of 3 parts; the first gives you the basic knowledge about the tool but also the basic understanding of the process and how to use the tool. The second part is a “worked example” that goes beyond the basic. Not only do we get to know more about Cucumber and it’s capabilities but also how to make sure that you are building a structure for you glue code that is maintainable over time. Also - there’s more in this part on the process and what works and not. The final part is more in the form of patterns and recipes and gives you techniques and approaches to handle common scenarios and situations, such as using Dependency Injection frameworks, testing web applications and APIs and running cucumber in a continuous integration tool.

Throughout the book there’s a very nice “this is not that hard really”-tone that I enjoyed throughly.

Even though I’m not a Java programmer (and through the examples in this book, I hope never will be either…. GOD some of it is verbose) I got a lot out of this book. I am a long time user of Cucumber on the .NET platform (SpecFlow as it’s known there), I even built part of the tool on that platform. Still I learned new things, tricks in the tool and ways to work with the tool that I haven’t tried before.

I cannot recommend this book enough. In fact, I’d recommend the book to anyone working with Cucumber, regardless of platform. It’s the best treatment I’ve seen on the tool.

Thank you!

Below you’ll find my detailed, but rough, notes that I wrote as I read the book.

Read on ...

Koa and the 'ReferenceError: Promise is not defined.'


M: “… hahaha, exactly. And speaking of RT*M, you know what I did yesterday?”

H: “No, but I like it already. Tell me more.”

M: “So I wanted to whip out a fast little Koa site. It’s sooo good for those”

H: “Yeah, I know. You told me like a million times.”

M: “Ok… sorry. Off to the terminal I went and went through the usual steps:”

mkdir newAwesomeApp
cd newAwesomeApp
git init
npm init
npm install koa koa-route --save
touch app.js
Read on ...

How we created the need for an emergency lane


In my last post I told you about some practices and policies around emergency lanes. Today, when I visited my client I realized that we, ourselves, had created the need for them. That’s great news because that means that we can also take that need away.

Let me explain what I mean.

Read on ...

Things I say often: I don't care about efficiency


I’ve talked more about effectiveness vs efficiency than you all care about. The reason for this fascination might be that the word is mixed up in Swedish I guess; there’s only one word for these both concepts. Boooh… Swedish.

Because the difference is paramount.

In the excellent book the Goal Dr Goldratt puts it like this:

Productivity is meaningless unless you know what your goal is

This is the same thing. I hear many people talking about efficiency, or that we should become both effective and efficient and yes, but all means, become efficient. BUT don’t speak another word about that until we all have a shared view on what the goal is. Without a clear goal - there can be no effectiveness. And then efficiency is pointless, as Dr Goldratt said.

My favorite explanation for the difference of effectiveness and efficiency makes this very clear;

Usian Bolt take the blocks. He has trained his muscles to perfection - they are very efficient for moving him fast. He has the latests experimental shoes from Pumaddike on - super efficient! No air resistant at all. The same goes for his clothing - they are super light, no air resistance. He knows how to get out of the blocks the fastest in the world. Even his hearing and reflexes are the best in the world. He’s focused. Everything around him is blocked out. Now the referee is calling “Set”. Usian Bolt is preparing his body.

BAM - the gun goes off. Perfect start! It’s the fastest ever measured speed in the world. His leg movements are amazing, his hands is held perfect.

But… he’s running off the track right into the middle of the field.

He’s very very efficient but not very effective. Because he didn’t know the goal.

All that efficiency… wasted.

Read on ...

Emergency lanes - some tips


One of the things that first made kanban known and loved was the introduction of emergency lanes. Or at least the lack of fixed scope for a sprint where sudden urgent work items was hard to handle in other methods.

Many kanban boards have an emergency lane. However often I see it abused (or being feared to be abused) and hence it will not be as useful as it could be. It’s a really great tool, both for “product owners” and the team alike. In this post I wanted to share some policies that I’ve found useful to manage emergency-lanes (or equivalent).

Read on ...

Things I say often: I run on feedback


This thing I say often “thing” is quite new and a bit personal. It’s very important for me personally and I hope that you like it.

I’ve had the great, but scary, opportunity to play a couple of times under the late James Watson. For any non-brass-players he’s one of the truly great trumpet players of the world, brought up as a wonder boy in the brass band movement. Later in his career he returned and made the world famous Black Dyke Band into a new being - possibly changing what people thought a brass band could be for ever.

Also - he’s know for being very … direct … even mean sometimes during rehearsals. But I fondly remember a lot of things from the hours I got to spend under his direction.

Read on ...

Things I say often: I'm into leadership - not management


This is just a short one. I don’t know where I picked the thought up, probably from David Marquet or Simon Sinek.

But really I’m so tired about talking about management for organisation and teams. Manage. That’s what I do with computer resources, stuff and sheeps.

I have higher thoughts for just about every person I ever met. If something these people need a leader. Someone that points, with clarity, towards the better future we are trying to reach, creates an environment where I can feel safe and give room and be challenged to be the best I can be.

I much rather talk about leadership and leading than management and managing. Leadership is what you use on people, management is for your pens or harddisks.

Read on ...

Make it smaller - some practical experiences


One of the “clients” I work with right now is a hospital. We have tried to turn their performance around and they are improving immensely. In fact - I think they will be just fine. I did not think that just 4 months ago.

One of the things that we have talked with the management team about is trying to do smaller things often and act on the feedback we get from that. Nothing new … in software development or other lean practicationers, but in this setting. I hear eyelids popping open everyday.

How does that look? What have we done? Most of the work we have done has not directly with health care to do but rather change management and business in general. Very practical stuff mostly. In this post wanted to share two of our current projects (or Focus areas as we call them) where our approach made a big difference.

Read on ...

Things I say often: NO! This is how you tear off a post-it


I’ve said this so often that we even wrote about it in the Kanban In Action. It’s not a book about tearing off post-it’s but it’s the printed kanban literature most geeky sidebar.

Post-it’s is such an integral part of agile that I’ve several times thought that the founding members probably own stocks in 3M.

I know embarrassing amounts of information about post-its; how it, accidentally, was invented, why the color is the pale yellow, why the glue is where it is, how to open a pack with one hand, or a knee etc.

But this simple little trick is something that most people I tell it to have not reflected about.

Read on ...

Things I say often: Improving means changing


I’ve already written about this before, but Hey - this was a series about things I said often.

Basically, but please read the other post instead, many times I’ve been at companies that want to improve but don’t want to change. This is impossible. Improving means changing. Changing doesn’t necessary means improving though.

To me this is one of the biggest misconceptions about agile; that it would be something that the IT-guys can start working with and we’ll all be better. It’s not. If you change something locally the impact will also just be local.

In the great book This is Lean the authors defines Lean as a business strategy. I like that and the same goes for agile:

  • it’s a strategy - there are many ways to reach your goal, this is just one
  • it’s about business. It’s not about the robots in your factory, just the developer or just the deployment script. it’s about how we do Business here.

My favorite example of this was at Swedish insurance company where I was invited to “help them get started with agile, to get faster time to market”. I’d say! When we started it was 9 months from idea to production, 22 different steps or decision points. Out of this time ca 4 days was spent coding.

Where did we start optimize? Yes, you guessed it. The other things was not IT and hence agile was not for them. “We can’t change that - it’s always been like this.” and “Hey kid, we’ve done projects like this for 25 years. Don’t come and change it now. Just get it better.”

That’s not only a tall order (like the kid-reference though, 39 years old at the time). It’s impossible. Improving means changing.

Read on ...

Things I say often: Why?


Really … this is probably the word I use most often. And I’m proud of it!

Why?

It’s not only because I’m ignorant and forget things a lot, but to me this is where knowledge is started to be created. I’m guessing I could write an entire book on just this single word, so this post will just be a few thoughts of the top of my head.

Read on ...

Things I say often: This is your board - change it


I have probably introduce around 80-100 teams to the use of some sort of board to visualize their work. One of the things that I often … ah, always say and also have to repeat is this:

Nobody has told us to create a board. We do this for us. This is great because that it means that we can change it how WE see fit
Read on ...

New series: 'Things I say often'


New year - new blog series. I was thinking about writing down some of the things that I find myself repeating often.

These post will be short, and possible link to places where I’ve already said this already.

I will collect these post under the label Things I say often

I don’t have a list made up already, so I’ll write things when they pop into my head. Here’s first things I that sprung to mind.

I hope you will enjoy this series. I know I will benefit from writing some of these down.

Read on ...

Best advice for me this year


When a year has passed I often try to think back and find the one most important thing I learned. This year that was a bit tricky since I’ve learned so amazingly much. So good - and some bad.

The single piece of advice I got that stood out was about presenting. And it came from one of my oldest friends, one that I call my brother: Kalle. Kalle is a pretty young guy but he’s very thoughtful and … yes I’ll say it: wise.

Another thing that stands out with him is the fact that he’s just become a Salvation Army Officer, a pastor if you want.

The advice I got from him was just before I was about to deliver my first ever “message”, or short sermon. I had asked him for all kinds of things about this but the final thing he left me with was:

The most important thing is to pray that you will become small so that the message will be bigger / clearer

or in other words:

You are not the most important thing!

BAM! It hit me like lightning; this is of course true for every presentation you ever give. You are not the most important thing - the message and how your audience receives / understands it is.

Sadly, when i look back, I have focused more on how I will present, how I will look or come out, will they laugh here, will they find me knowledgable. Not on the message.

But not since that comment. This simple little sentence made me restructure my presentations but mostly gave me a new approach to my material. Even old material was improved just by approaching with another goal.

Thank you Kalle! I am better thanks to you.

Read on ...