Niels Roesen Abildgaard

software development and other things

Read this first

Ethical Implications of System Accountability

Security for the user or security for the company?When software developers build large systems with accountability of users they are empowering the companies that own the systems while potentially endangering the system’s users. The alternative is building systems with deniability, which turn out to be more akin to systems from the pre-digital world.


Hello software developer, I would like to talk about how we think about the systems we build. More precisely, I think we have a tendency to think about concrete details of our systems, sometimes missing the bigger picture.

When we build systems, we want them to be secure, right? How do we talk and think about security, then? Are we missing something?

A lot of the time, I think we are too entrenched in the current way of doing things, the status quo. As new developers, in particular, we are taught and socialized to build systems in a

Continue reading →


Faster web apps by hiding processing time: a lightning talk

This is your web server:

A single box, "your web server", on a blank plane.

This is a client, making a request to your server:

... a person is added, with an arrow pointing from the person to the web server box.

A web application consists of both the client and the server. The client might be a browser, that beautifully renders the HTML, CSS and Javascript you send back. The actual user interacts with the browser.

Sometimes a client doesn’t have a human user. It might be a different system.

Anyway, we don’t care about the user. We care about how fast your web application is. And right now, a client is making a request to your web server.

Your web server is eager to please. So it makes a request to your database:

... and a database is added, with arrows from the server to the database, and back

Actually it needs a bit more information:

... another set of arrows is added between server and database

Now the web server has recognized the client. Let’s start getting the information we need to put together for a response to the request.

... then some more arrows. And even more!

To some of you the server may seem extremely frivolous about its number of queries, but this is a fairly common

Continue reading →


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 →