Niels Roesen Abildgaard

software development and other things

Read this first

New hires are an opportunity to reevaluate

Your company’s development team is fairly stable. It’s the same people working together every day. That stability makes for great things: it improves the quality of team work, makes for more constructive feedback, and builds a shared vision for what the code base should look like.

Hopefully the stability doesn’t mean that you aren’t trying new things. Hopefully you are still evaluating new technologies, reevaluating past choices, and figuring out new ways to approach design that might be a benefit to the readability and extendability of your code.

Then you hire someone new.

That brings with it a lot of things. You will spend a lot of time bringing the new developer up to speed, transferring knowledge from the team to the new member, teaching them to develop the way you develop and how the code base works. So they can pull their weight.

It probably also leads to the new developer

Continue reading →


Hide processing time from the user

What happens in a regular old web application when a user makes a request? This web application could be built in Drupal or Ruby on Rails or Django. These frameworks all, on a very general level, share some characteristics — and not just because they are MVC frameworks.

Dynamic web applications built with these frameworks share the characteristic that they build responses on request. This is so trivial, and such a common pattern, that it is rarely questioned.

They share the pattern that they handle requests in roughly the following steps:

  1. Receive and understand request
  2. Query a database for some information
  3. Transform data into a response
  4. Send response to the user

Receiving requests and sending responses are required for a web server to be considered a web server, so these hardly need further exploration.

Querying a database may take different forms. Even as it has become possible

Continue reading →


Investors are Overhead

When a business takes investor money, the main goal of the company becomes making that investment worth it. Publicly traded companies compete on having people believe that the investment will be worth it, any companies with stocks will be valued through the value of its stocks.

Being measured on stock performance changes the entire dynamic of a company. The goal is no longer to build a product, but to build stock value. “[The] product is the stock,” as fictional Jack Barker says in Silicon Valley.

This may create problems. I will try to illustrate what companies with investors usually miss out on, and why. To paraphrase a common saying of Elon Musk’s: you get what you incentivize for.

Investment has become the norm in software development, so much that the few companies that are privately owned are seen as radical rebels — or at least daring to be different. Basecamp and Valve are two

Continue reading →


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 →