Niels Roesen Abildgaard

software development and other things

Read this first

Time to Breathe

In software development there is a tendency to add, add, add, change, change, change—even when the additions or changes are not of any value.

Inspired by the ideas of Minimal Viable Products and iterative software development, but forgetting the most important parts of those, we end up rapidly iterating but not really waiting or accounting for feedback.

A team usually works on a single project, pushing the development with all the velocity they can muster—and when they realize they have been pushing in the wrong direction they turn around and push in the opposite direction, once again with full force.[anecdotal]

This is wasteful. But it is also endemic of a larger problem.

Anders Enghøj and I recently launched Mærkelex, an encyclopaedia for scout badges in Denmark.

We spent a total of 5-6 man days developing before launch, including the time we spent inputting the data on badges

Continue reading →


90% of software is shit.

(At least) 90% of software is shit. It’s slow, nigh on unusable, and unstable at best. Let’s change that.

This is a short collection of general advice that most software developers do not adhere to—adhering to it will facilitate a way of thinking about software that should make it slightly harder to build the bad kind.

All of these tips will be very generally applicable. I have steered clear of recommending (or recommending not using) processes, as company politics will often make it hard for develoerps to change these. All of the advice is meant to help developers make a change.

Is it the fault of software developers when software is shit? Rarely. But they can make a difference. Here’s how.

 Do the leg work

You are going to have to start reading. If you think you are magically better than all the people who came before you in the industry you are wrong. Never stop trying to get

Continue reading →


My First Event Sourced Application

Back in 2011, in my first year on the BSc Software Development, I built a link shortening site. The project was pretty much abandoned within half a year and has been lying dormant since.

This is how the main page of the site looked:

drng.dk front page

I have recently started migrating things to a new server, and that brought me to reevaluate the site. It is currently offline, so you will have to rely on the pictures I show here for an idea of it.

One part of the application is showing statistics over who has visited a link. This happens by recording a visit whenever a visitor accesses a link. For example, if you visited http://drng.dk/1 the application would record your user agent before sending you off to the destination, http://hypesystem.dk.

I wanted to show a breakdown of what browser and operating system a user was using to visit the site. When I was creating the data model and the corresponding

Continue reading →


Overview 2015

In 2015, I started drawing things that I wrote about. I also started writing a whole bunch more. Here is an overview of some of what I wrote during the year, including all the illustrations.


Image: "Team Leader attends the meeting so the developer can concentrate on developing"

 Leadership and Workplace

Team Leaders Should Shield Developers was my first claim about leadership. It is impossible to get anything done while being constantly interrupted or while under constant pressure. It is the (tough) job of Team Leaders to deal with the pressure, and relieve the developers of it, I argued.

In the image above, a Team Leader is at a meeting while the developer gets some work done.

pingpong.png

In Workspace Ownership, I argued that the best work is done in a workspace where the developer feels comfortable. Comfortability can, for example, be achieved by allowing fun (and useful) activities, such as pingpong, in the office.

developersendsemail.png

Most popularly, in this category, I wrote about what I

Continue reading →


Note: debouncing

Adding debounce to a function results in the function is only run once a break has occurred in triggering.

 Simple debounce

If a user is typing in an input field (a search field, for example) you don’t want to perform a HTTP request for each keystroke. Debouncing the keystroke listener will result in a HTTP request being sent once the user stops (or has a break in) typing and not before.

Debouncing is implemented with a debounce function, which takes a inner function (the action) and a delay (the time that should pass with no triggering before the action is taken).

My best suggestion for a simple debounce function (after writing something, then looking at the one in lodash, the one in underscore, and finally stumbling upon a great one by @rem) looks something like this:

function debounce(fn, delay) {
  if(typeof delay == "undefined") {
    delay = 250;
  }
  var timer = null;

Continue reading →


I wouldn’t recommend process

Back in February 2015 (a year ago!) I wrote that I wouldn’t recommend Scrum. Looking back I see that I was merely grasping at the end of a bigger concept.

Here I will try to clarify and generalize from the original post.

I would like to reiterate that I do not think Scrum is bad nor did I argue so in the original post. I understand that, based on the title, it is reasonable to assume that that was my point.

This post is called I wouldn’t recommend process but I do not mean to say that processes are bad and should be avoided. Processes can be valuable, as long as they are not overly bureaucratic and do not get in the way. Processes are helpful when they codify what is already being done and free up cognitive resources.

Image: Daily Standup with the Team. Updated version (based on the one in I wouldn't recommend Scrum) with colors.

My first introduction to the world of Agile software development came through Extreme Programming Explained (XPE) Second Edition. Extreme Programming is known by

Continue reading →


Note: Good-looking text flow

If you want your text to flow nicely on responsive web sites, there are two tricks I like to use: soft hyphens for optional break points, and text-overflow ellipsis for situations where there is only room for a limited amount of text.

One at a time, now.

 Soft hyphens

A soft hyphen ­ is an optional breakpoint for a word. The browser will determine, when layouting, if this breakpoint should be used. If the word extends across the right-most side of the box it is in, it will break.

I made a quick little example with a resizable box that lets you see the effect.

Soft hyphen

This will also work as your layout shrinks and grows, making your text look good, with text lines of similar length.

We used this on Mærkelex to make sure the names of badges were always readable, even at very dynamic sizes of containing divs:

Soft hyphens on Mærkelex

 Text-overflow

You probably know about the CSS attribute overflow. It lets

Continue reading →


Explicit Plurality

Here’s a quick idea for making your code more readable.

In your code you want a method to get a specific user, getUser, but you also want a method to get all users, getUsers. These two functions will inevitably have different interfaces:

db.getUser(id); // id distinguishes this user from others
db.getUsers();

As a developer you spend a lot of time writing code, but even more reading it. While the distinction between User and Users is clear enough when writing it, it is easily overlooked when skimming through code. A mistake, such as leaving out a letter, can easily be overlooked because the reader expects the correct form to be used.

My colleague Asbjørn Thegler made the excellent point to me that there is a simple solution for this: be explicit in plurality.

This means writing getAllUsers instead of getUsers, lessening the similarity between the singular and plural forms

Continue reading →


Promises, Plans, Goals

I don’t have any New Years Resolutions for 2016.

My New Years Resolutions for 2015 — the first New Years Resolutions I’ve ever made — were:

  1. Publish 24 blog posts
  2. Publish an illustration or drawing each month

The tally at the end of the year was:

  1. 22/24 (no posts in December)
  2. 11/12 (no drawings in December)

So, I failed. I failed to reach the goals I set at the beginning of ‘15. That’s the simplest way of putting it.

Image: Candle

Many people see resolutions as promises made to themselves. I chose deliberately not to. Breaking a promise to yourself is a horrible and harsh thing to do, and definitely not something that anyone would want to become a habit. Making promises only to break them is lying to yourself, and that is never good. Moving forward requires being honest with yourself.

Seeing a resolution as a goal (not a promise) changes things. A goal is something you strive for. Something

Continue reading →


Relearn and Remember

This is a general lesson I learned and it is a story. It’s also about software. Eventually. I swear!

I went to the pharmacy to get a new pack of astma medicine. I had been to the doctor recently, because I felt like my astma had been getting worse. I had gotten short of breath from trivial exercise, like cycling a bit fast. That doesn’t normally happen.

Image: Inhaler.

“Do you know how to take the medicine?” asked the woman behind the counter. I had heard that question before. I had always politely declined their offer to show me how to use the inhaler—after all, I had used it for years—but this pharmacist was friendly and grandmotherly and when I said that I had been taking the medicine for years she said that maybe I had forgotten how and she made it sound like a friendly suggestion instead of accusatory and doubtful. So I said yes. Please. Maybe I have forgotten.

I paid for the medicine, she put

Continue reading →

no