Niels Roesen Abildgaard

software development and other things

Read this first

Stagnation and Tunnel Vision

It is easier to learn when you are young. So I have been told all my life.

According to research on neuroplasticity the brain continues to grow and learn from what it is exposed to—it never stops.

As we get older, life is filled with more routine. Get up, 9-to-5, relax, cook, sleep, repeat. That is a pattern I see in many adults around me.

I am 24, and in a sense I have refused to grow up (“it’s a trap!” I was told). I have refused routine. I could never make it work.

Adults are much busier with the little things of life. That I have not escaped.

Just recently I picked up a musical instrument for the first time, a Ukulele. I’m not very good but I taught myself some chords and some strumming quite quickly. It didn’t feel like I was slow at learning.

Sure, I haven’t become a master of the instrument, but I haven’t invested the huge amounts of hours into it that I would invest into

Continue reading →


A get rich quick scheme, maybe

Hey, remember Bitcoin? The cryptocurrency that wasn’t really a serious thing, most likely a fad, something that was going to pass quickly without leaving much of a mark?

Well, today one Bitcoin is worth more than $1000 dollars.

In 2010, an urban legend goes, someone bought two pizzas for 10000 Bitcoin. Today, that’s worth more than 10 million dollars. Expensive pizzas!

Expensive pizza!

The value of Bitcoin has exploded, and cryptocurrencies are very likely going to be with us for a long while. As Bitcoin saw wider adoption and support in applications, its value grew.

Maybe the wild increase in value we saw with Bitcoin wasn’t the last of its kind. Maybe there’s money yet to be made in cryptocurrencies.

There are some problems with Bitcoin. It is anonymous in that no name is tied to a wallet, but transactions are still traceable. Remember that whole thing about how much NSA can learn about you from

Continue reading →


Three Thoughts on Amazon Go

Amazon just released a video explaining the concept for a new kind of grocery store, with no queues and no cashiers and no waiting. Here are three thoughts on the implications of the technology and concept.

The idea behind the store seems to be that customers check in with an Amazon account to enter the store, and are then watched by the store itself while they shop. The store determines, using “Computer Vision” and “Deep Learning Algorithms” similar to those in autonomous cars, what each customer picks up. Customers can simply walk out of the store when they are finished, and their Amazon account will be charged. A receipt will be visible on their Amazon app.

The full video is right here:

The technology is really exciting, and the execution is interesting: the store has become one big device, interacting with people and their devices. This is a crushing blow to the idea behind

Continue reading →


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 →