Erik I

My public writing. You can reach me at

Filed under #testing and #softwareengineering

In a discussion about Kent Becks post Test Desiderata someone asked when they are inexperienced in software testing but still the only one on the team that care about writing tests. I answered it briefly on my way to work yesterday but I'll try to clean it up a bit and add it below as it seemed useful.

But first: if you are at all interested in testing and haven't read Test Desiderata yet, read it. Kent Beck is famous in the field of software development and for good reason!

That said, here is what I wrote, expanded and edited somewhat. The context is still someone who tries to write tests while nobody else cares:

Testing is primarily a tool

Always remember, and particularly if you are alone fighting a good fight to improve quality: if nobody has told you to test and what tests to write then they are just a tool to help you.

I think I was lucky when I was introduced to testing as the guy who introduced our team to it presented it as a tool to reduce boredoom and busywork instead of as a “best practice” that should ideally be followed to be nice.

In his words (as best as I can recall them, and with apologies if it turns out he quoted someone else):

Only software developers launch the entire space shuttle every time they want to test a small change they've made.

Every other engineering discipline uses a test bench or text fixture.

  • Glenn Richard Bech, sometime in 2007 or 2008

He then went to prove how we could often save time by testing our new features automatically in 15 seconds flat or something like that instead of having to wait forma full server restart that could easily take 2 minutes just to get to the point where we could start manually verifying our changes.

Start small

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. John Gall

This law holds true for testing as well.

(And if you can keep things simple while expanding it to cover all needs – all the better!)

When planning, look for tests that will speed up your work right now

I often find that adding a minimal test suite will speed up my work significantly.

By starting with those tests you will be building confidence for yourself and goodwill for your work. After all no reasonable boss will get angry with someone who is successfully working to do their work faster and more effectively.

Getting upset if they feel someone is spending time on unnecessary busywork however would be understandable.

Don't care about overall coverage, only that what you are working on now is reasonably tested

Stay with your work. Don't switch context just to improve some statistics.

In addition to the context switches, it also creates noise.

Observe and make at least a mental note when the tests are help you

Your tests can work as both a

  • lab bench, keeping your code in place while you work on it
    • how? write a simple test that feeds the code the inputs that are currently working to make sure nothing breaks.
  • fall protection
    • how? check in the code, run everything at least every time you are about to push new code, and – especially if nobody else cares – after you check i n code from others: to verify old important code still works.
  • a colleague that does pair programming with you, pointing out when you are about to forget something important
    • how? it is hard to explain but you'll hopefully experience it.

If some advice you get doesn't make sense and you can ignore it, do that after trying to understand what it should help for

Don't waste time just because someone says something is a good idea. In keeping with the ideas above keep your tests lean and focused on value add and removal of tedious work instead of focusing on doing it “right”.

So much time is wasted every day in discussions both in teams – but also inside peoples minds – about the correct way to do things. Just don't be so open minded your brain falls out.

(And for anyone working in a team: most of the time, stick with the rules.)

Michael Feathers book “Working Effectively with Legacy Code” might come in handy at some point

If you work late with legacy code this book might help you. If you don't have time can however probably manage without as well 😏:

A couple of months in the laboratory can frequently save a couple of hours in the library.

Frank Westheimer

Filed under #music

These days I always start my days listening to a podcast I find interesting, but during the work day I often listen to music. Today I came across this track that I immediately loved:

Filed under: #lifeInNorway, #observations and #photo

The last couple of years we've seen a huge diversification of bikes and I'm hoping to get some usable photos of all kinds of weird and wonderful bikes-with-electric-motors. (My phone is too slow to catch them in use ;–)

So for now, here are some ordinary bikes parked under a bridge: Ordinary bikes under a bridge.

Also E-scooter companies have been really busy trying to become a trend this year, but haven't succeeded yet as far as I can see. Here are some of them:

E-scooters standing in line under a bridge trying to become a big trend this year. It is dark enda

Filed under #thingsIRead, #learning and #teaching

If you want to share this, please share the original link below, not this post.

My words here are just context for why I share it with my readers. This blog is not a SEO experiement, and the world need less SEO, not more.


I'm a bit facinated by learning, and this post resonates a lot with my observations.

See also, an example that I relate less to but still think explains the problem.

Filed under #observations and #books

I'm currently listening to “Getting Things Done” by David Allen.

This is a revised edition of the original and I find it even easier to relate to. It is also more than ten years since I read the original and I'm realizing that I've been further away from the ideas than I thought. I probably wouldn't have appreciated it so much however if I hadn't been experimenting so much the last >10 years.

I'm also reading the draft of the third edition of “Security Engineering”by Ross Anderson.

The first chapters are freely available and – in my opinion – probably very well worth reading if you work in a tech related position where your decisions in any way affects the product.

I also find myself reading the Bible more.

After all, life is short, and in the words of someone else: “[to be more effective] do more of what works.”

Filed under #lifeInNorway, #observations and #howto

(Might apply for other Scandinavian countries and certain other countries as well, see video of Swedish people waiting at the bus stop at the bottom of this post. )

As you walk into the bus, scan the seat rows.

  • Some seats are prioritized for elderly and disabled. Stay away unless the bus is empty anyway.

  • Try to find two empty seats next to each other, take one, put your bag in the other.

  • Generally within reasonable limits try to contribute to an even distribution of peiple in the bus.


  • If you see a friend (who's not extremely close friends,) or someone you know, smile and say hi or nod.

  • If you cannot find two empty seats, pick one based on the following list:

  1. Someone you know

  2. Someone else

Take with a grain of salt, and always apply common sense. Also it is a bit short; I wrote it in around 15 minutes, on the bus.

BTW, avoiding people on the bus is seen as polite, even if you know them.

Will try to get back with some advice on how to pick a seat on the train (if you can get one, that is 😎 )


Filed under #observations, #risingearly and #lifehacks

Another work day where I wake up early. But I've made a change to my early morning habits:

The plan is now:

  1. Get out of bed as soon as the alarm goes clock off
  2. Press snooze
  3. Get dressed
  4. Go downstairs
  5. Turn off the alarm
  6. Make coffe
  7. Press play on the podcast I am listening to
  8. Start browsing Instagram
  9. Stop browsing when podcast episode finishes

The second last item on that list might sound weird to almost everyone else but I can forget looking at or even thinking about Instagram for days or weeks.

That might sound great for someone who struggles with addiction to social media, and I guess it is less annoying and dangerous,but also means I miss out on a lot of what is happening.

So for now I'll try this to see if I can include a healthy dose of updates from friends and family.


  • it helps a lot that I have decided well in advance what the first 30 minutes of the day will look like
  • it works reasonably well, my brain turns on (possibly related to an interesting podcast)
  • generally my brain seems to respond well to spoken words while I'm doing something else
  • Instagram ads generally have a lot better targeting for me (it took 12 long years for Google to realize I was not looking for scammy-looking dating sites)
  • writing blog posts takes more than 5 minutes, I guess this took 30 minutes
  • it is now 0522

I've been trying this for less than a week, so add a pinch of salt, but I feel I'm into an habit that can work well for a few weeks.

Filed under #observation, #lifeInNorway and #lifeOnTheInternet

Today the orange forum is discussing “matpakke” (link to vox article about matpakke.

As usual it seems other peoples boring routines are more interesting than ones own boring routines. Which is kind of understandable since it is less boring the first time.

And to be clear: matpakke is probably a good – but boring – idea.

Filed under #opensource and #observations

I wrote this the other day:

Also you can ask 20 honest developers what they think AGPL means and get 3 or more wildly different explanations, at least if you include “I've no idea except it also works lver the network”.

Besides the typo I immediately also go a message that I could stop spreading FUD and instead point people to

Which I have hereby partially done by adding that link.

My point still stands: developers don't know what the AGPL means, and here are two, just from the replies to my comment:

Edit: I should point out that I find these to be very reasonable and not too far from my understanding of AGPL.

Is it not “if you take AGPL code and run it on your server and make it available to other people, you need to give them the code to whatever you're running”? saagarjha

It's the “whatever you're running” that gets complicated if you're using the AGPL code in conjunction with a bunch of other code to deliver some service to customers. What are the rules around how that other code is allowed to interact with the AGPL code before it has to be made available as well? ghaff

And this is just the beginning. I think I've even seen people moving to AGPL while claiming that it wouldn't affect its users at all (the project in question used to be MIT licensed IIRC.)

While I personally think most software should be licensed under permissive licenses such as BSD, MIT and Apache I haven't seen any problems with AGPL.

It is however clear to me that the FSF has some work to do to get people to understand what the AGPL allows and doesn't allow.

Filed under #java and #dotnet

I got a couple of questions about Java, the answers became so long I decided I could rather post them here.

As usual everything here is a draft, otherwise I wouldn't have time to finish it.

(Questions modified to fit tve format.)

Why did Java become your favorite language even if you didn't like it from the beginning?

About ten years ago I worked simultaneously on Java and Delphi and PHP and had some experience with Javascript (coded a map viewer in JS and SVG) as well as a little bit C from school etc.

This was just at the time when Maven came and our tech lead introduced it despite some unhappy sounds from our boss.

At that time we lost days of work (and used a top consultant for three days) first hunting dependencies for Delphi then having to install them in the right order and with the correct incantations in between.

I also had plenty experience with hunting for typos in Javascript anf PHP. Remember this was 10 years ago, long before Babel, Typescript, linters and what not.

Java on the other hand just worked. No squiggly line meant it would compile. Hunting for and manually updating dependencies became a thing of the past as we introduced Maven, and even with Ant it was OK compared to the mess that was depencies in e.g. Delphi.

The difference in ergonomics when coding was also day and night. With Java and a good IDE typing was reduced, typos were gone, all information you want would be available reasonably quickly (even if this was back in the days of spinning disks), and the refactoring story of Java was one of a kind back then and second to none even today IMO.

The last thing I disliked about Java was the insistence on xml heavy frameworks as well as the fact that the setup we used at that place took two minutes to restart and had to be restarted for code changes to take effect.

At that time though I started to rely on automated tests for business logic which cut down on server restarts and I also learned to use the debugger in my IDE which meant I could finish troubleshooting without restarting the server.

And why only for a decade?

I still like it a lot. It is still my favorite ecosystem. All the xml is gone now from all mainstream frameworks. And I sometimes miss Java features and editor features even when I program in C#. And yes, I too liked Java even better after Java 8.

Meanwhile I can now program C# without selling my soul ;–) Both dotnet and VS Code works extremely well on Linux, has a less ugly company to back it and has had the benefit of learning from the extremely successful business language that is Java to make an even better language.

Enter your email to subscribe to updates.