Simple .NET standalone web server

The other day I got frustrated that I couldn’t find a code example of a simple .NET OWIN standalone (i.e. not using IIS) web server (i.e. not a REST server) for .NET. After some research and trial-and-horror I came up with the following:

using System;
using System.Diagnostics;
using System.Net;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
using System.Web.Http.SelfHost;

namespace WebServer
    class Program
        static void Main(string[] args)
            const string serviceBaseUri = "http://localhost:4578/";
            var config = new HttpSelfHostConfiguration(serviceBaseUri);
            using (var server = new HttpSelfHostServer(config, new MyMessageHandler()))
                Console.WriteLine("Press Ctrl+C to quit.");

    public class MyMessageHandler : HttpMessageHandler
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
            var res = new HttpResponseMessage(HttpStatusCode.OK) { Content = new StringContent("Hello, World!") }; 
            var tsc = new TaskCompletionSource<HttpResponseMessage>();
            tsc.SetResult(res);   // Also sets the task state to "RanToCompletion"
            return tsc.Task;


Technical debt

My preferred definition of technical debt is:

Technical debt is existing (technical) structures that stand in the way of making the next change. The interest is the cost of having to deal with those structures in your day-to-day work, and the down payment is the cost of making the structures apt for use.

Debt can be intentional in that you take shortcuts to meet an important deadline or to hit a market window. In this case you have an expected ROI for the loan you take, one that you hope will pay off more than the cost of later fixing the shortcuts taken.

Debt can also be the unintentional, and here it gets interesting. One type of debt is that which results from sloppiness, usually resulting in a messy code base. This type is not related to any kind of investment, hence there is no expected ROI, it is just like  a loan for consumption of drugs; it will destroy you (your code) and your economy if it doesn’t stop.

By the definition above, debt can also be the result of external events, sometimes out of your control. Your perfect system can suddenly become your largest debt if you go from one to several customers, the company strategy changes, the market changes or laws change.

Some people, among them Uncle Bob in this article, argues that messy code is not debt. I disagree, for the reasons above. I think Uncle Bob and others confuse debt that results from loans taken to make an investment, and debt resulting from neglect, lack of experience or incompetence. The cause is totally different, but you’re still in debt.

There is no reason to make a messy system, since there simply is no return on that investment. Accept debt only to take loans that enable you to make a sound investment.

Start Paying your Technical Debt – The Mikado Method

[at we will put more information on the Mikado Method]

A couple of years ago, Ola Ellnestam and I was working on a project where the code was a big ball of mud, or at least well on the way there. Global variables and singletons all across the code base, circular dependencies, deep and fragile inheritance hierarchies etc. The Technical Debt was everywhere.


All of a sudden we were supposed to deliver to a new client and the interest on our loan went through the roof. The reptile response from several developers on the team was to copy most parts of the code base to a new project and modify the code there. This would double our debt, but decrease the interest temporarily, until the next client would drop in. We fought with all we got to avoid doubling our debt and in the end we had convinced everybody that we could re-factor the code-base, just give us a week or two…


You get what you measure

Yesterday I watched Grand Designs on TV where a couple restored an old 1600-century house. They found that at least one window was shut with bricks and concrete (or the equivalent used at that time), but when they opened it up the whole room changed and the light and the view the window provided was beautiful.

The reason for shutting the window, as Kevin McCloud told, was that long ago there was a window-tax (!!) in England, hence a lot of windows where shut this way.

You get what you measure.