Bifrost and Proxy generation

Originally posted on :

One of the things we consider to be one of the most successful things we’ve added to Bifrost is the bridge between the client and the server in Web solutions. Earlier this year we realized that we wanted to be much more consistent between the code written in our “backend” and our “frontend”, bridging the gap between the two.  And out of this realization came generation of proxy objects for artifacts written in C# that we want to have exposed in our JavaScript code. If you’re a node.js developer you’re probably asking yourself; WHY..   Well, we don’t have the luxury to be writing it all in JavaScript right now, but it would be interesting leveraging what we know now and build a similar platform on top of node.js, or for the Ruby world for that matter – but thats for a different post.  One aspect of our motivation for…

View original 928 more words

Sustainable Software Development

Software is hard to make, capturing the domain and getting it right with as little bugs as possible. Then comes release time and your users starts using it, things get even harder – now comes all the changes for all the things that you as a developer did wrong, all the bugs, things you didn’t think of, misunderstandings. All that and the users have requirement changes or additional features they’d love to have on top. I’ve often heard people say things like “… if it wasn’t for the users, creating software would be quite joyful …”. It says tons, it does say amongst other things that creating software is not an easy task. Also, it does say a bunch of other things as well, for instance – it says that we’re not very good at talking to our users, or we’ve taken the concept of having your team working in black-box environment too far or too literally.

Even if we did it all right there are tons of external events that could cause the requirement of changing what we already made. The market could change, new competitors arriving to the table or existing competitors taking a completely different approach to the same problem you just solved. Another aspect that can cause changes is that the people we develop the software for that we’ve included in the dialog are learning all the way through the process of what is possible and what is not, causing them to have more knowledge and wanting change.

The purpose of this post is to shed some light on what we think are good practices on their own but put together represents a very good big picture of how you can create software that will easier to change, meeting the requirements of your users better and possibly reduce the number of bugs in your software.

Talk Talk Talk

One of the biggest mistakes I think we do is to think we are able to intuitively understand our users, what they need and want and also how it should take form. Going ahead and just doing things our way does not come from an inherent arrogance from us developers, but rather something I think is closer to an what we consider an intelligent and qualified assumption of what we think we’re making. At the core of this problem sits the lack of dialog with the real users. We as developers are not all to blame for this, of course. On unstructured projects without any particular process applied one finds very often that users or representatives of the users, such as support personell, sales persons or similar have a direct link to the developers. If you’ve been on a project like this, you’ll probably also remember that there was especially one guy in the office these guys went to – he was the “Yes Man” that just jumped and fixed that “critical” bug that came on his desk. This is needless to say a very counterproductive way to work; at times you’re not able to get into the zone at all because of all the interruption. Then on more mature teams they’ve applied something like ScrumeXtreme Programming or similar and been taught that we run demos for the end users or their representatives at the end of an iteration of X number of weeks and then they can have their input into the process. It gaves us the breathing room we were looking for, phew…

The only problem with this breathing room is that it is often misinterpreted and taken too literally. During an iteration, there is nothing saying you can’t speak to a user. In fact, I would highly recommend we do it as often as possible, so that we’re certain that what we’re making is really what the users want. We don’t know, in fact, unless you’re making software that you’re using yourself – like a dev tool or something else you are using on a regular basis, we really haven’t got a clue whatsoever. Even though opening up a communication channel like this sounds scary, and it should sound scary if you’ve ever been on the an unorganised team. Communication is key; make it so that you as a dev contact the users or their representatives and they can’t go to you directly for anything – unless agreed to because you’re working on a particular feature together. So in conclusion; users don’t speak to the developers about things they aren’t working on with the developer – if they’re working on something together, they should be the best of buddies.

One of the practices that can one could consider applying Domain Driven Design (DDD), which comes with a vocabulary in itself that is very helpful for developers. But the best part of DDD is the establishment of a ubiquitous language, a language representing the elements of your particular domain that both the users speak and the developers. Often this means representing the vocabulary the end users already have in your own code. Getting to this language will help you communicate better with the end users and you don’t have to do mental translations between what the users are talking about and “what it really is” in the code.

The secret sauce of agile

We’ve all been touted our ears full of how we have to become agile. You would be crazy to not do it, we’ve been told. I think its important to clarify what agile means; its all about feedback loops. Get the software into the hands of the users as fast as possible and often as possible, so that we can learn what works and what doesn’t. Find problems as early as possible when it is still fresh in the minds of the developers – leading to saving time in the long run and increased quality of the user experience and code.

I’m all in, keeping the feedback loop as tight as possible. In fact, the part about the feedback loop and keeping it as tight as possible is something I promote all the time as well – for just about everything from execution time of your automated tests to feedback from the real users. One of the promises of being agile is to be able to have software that is changeable and adapt to input from users. But I would argue that there is part of this story that seems to drown in the overall messaging; your software needs be written in a way that it is agile. What does that mean? I think there are a few basic techniques and principles we can apply to make this a reality.

Testing is one of these pieces to the puzzle. Writing code that verifies the production code and its promise is something some of us has been doing for quite a while, in fact I would argue – everyone does this, but not necessarily consciously. Every time one adds a little console app or something to test out a particular feature in the system that you’re developing – just to keep you from having to run the entire app every time, you’re then putting in code that you can more easily debug what you’re working on in a more controlled way. These are in fact tests that could with a small fine-tuning become automated tests that can be run all the time to verify that you’re not breaking anything while moving forward. This gives you a confidence level to be able to change your software whenever change is needed, typically due to requirement changes or similar.

Also, your tests becomes the documentation representing the developers understanding of what is to be created. Applying techniques like specification by example and BDD, your code becomes readable and understandable for other developers to jump in and understand what you originally had intended without having to explain it verbosely to another developer. By being clear in the naming of your specifications / tests, writing them out with the Gherkin language, you add the ability to really look at test / spec signatures and have a dialog right there and then with a user.

But with testing comes a new responsibility, the ability to have code that is testable. All of a sudden it can feel painful to actually test your code, due to complex setup and often one ends up testing a lot more than needed. The sweet spot lies in being able to mock things out, give fake representations of dependencies your system under test might have and test the interaction. Testing in isolation is the key, which leads to a couple of things that you want to consider when writing your code; Single Responsibility Principle and Interface Segregation Principle. Both of these helps in testing, but are on their own good practices and makes your software ready for change. With SRP, your code gets focused and specialised – having a type represent one aspect and a method only do one thing, all of a sudden your code gets more readable as well. Applying ISP, you have contracts between systems that aren’t concrete and these can be swapped out, giving you great opportunity for change but also makes it a lot easier to test interaction between systems as you now can give them fake representations and all you need to test is that the interaction between them are correct. All this again leading to higher focus and in return in the long run giving you as a developer greater velocity and confidence in changing your implementations.

I strongly feel that testing is a necessity for agile thinking, it gives you the power of changeability, and often forgotten as a vital part of the big picture.

Rinse repeat; patterns

When developing software for a while, one finds things that work and things that doesn’t; patterns and anti-patterns. These are often organically appearing by plain and simple experience. And some of these patterns have been promoted and been published in literature. Patterns are helpful on many levels; they give you as a developer a vocabulary – making it easier to talk to other developers. They also provide guidance when you not necessarily know how to do something – knowing a few well known patterns can then become very powerful.


Software can be divided into logical parts that are concerned with different things. In its simplest form you can easily define things like what the user sees and uses as its separate concern, it is the UI, frontend or the View. Then you can also pinpoint down to what is the place that performs all the business logic, the thing that represents the vocabulary of your domain. Going back into the UI we can be even more fine-grained, you have the concern of defining the elements that are available in the UI, then you have the concern of styling these elements and making them look like you want to and thirdly the concern of making them come to life, the code that serves information into the UI and responds to the users actions. Right there in the UI we have at least 3 concerns. Translating this into the world of web this means; HTML, CSS and JavaScript. These are three different things that you should treat very differently, not in the same file with <style/> and <script/> tags all over the place, separate them out!

On all tiers in an application you have different concerns, some of them hard to identify and some just pop up, but they are nevertheless just as important to find and identify them to separate them out. Sometimes though, you run into something that applies to more than one thing; cross cutting concerns. These can be things you just want to automatically be used, or is something your main application does not want to think too much about. The classic example of such things are transactions, threading and other non-functional requirements. Something that we can technically identify and “fix” once and not have to think about again, in fact they often have a nature of being something we don’t have to think about in advance either. But there are other cross cutting concerns as well. Take for instance a scenario were you have the need for a particular information all over, something like tenant information, user information or similar. Instead of having to pass it along on all method calls and basically exposing your code to the possibility of being wrongly used, you can simply take these cross cutting concerns in as a dependency on the constructor of your system and define it at the top level of your application what that means.

Identifying your different concerns and also cross cutting concerns makes life so much simpler. Having cross cutting concerns identified makes your code more focused and easier to maintain and I would argue, more understandable. You’re not getting the big picture when looking at a single system, but nor should you. Keep things focused and let the different systems care about their own thing and nothing else. In fact, you should be very careful about not bleeding things between concerns. If your UI needs to have something special going on, you should be thinking twice about introducing it already in the business logic often sitting on the server. A classic example of this is to model a simple model of a person holding FirstName and LastName and then introduce a computed property holding FullName. FullName in this scenario is only needed in the UI and gives no value in polluting the model sitting on the server with this information. In fact, you could easily just do that in the View – not even having to do anything in the view logic to make that work.

Fixing bugs – acceptance style

There is probably no such thing as software completely without bugs – so embrace fixing bugs. You will have to fix problems that come in, but how you approach the bug fixing is important. If you jump in and just stunt the fix disregarding all the tests / specifications you wrote, you’re really just shooting yourself in the foot. Instead, what you should be doing is to make sure that you can verify the problem by either changing existing tests / specifications to accommodate the new desired behaviour or add tests / specifications to verify the problem. Then, after you’ve verified the problem by running the automated test and seeing that it is “green”, you go back and fix the problem – run the automated test and verify that it has become “green”. A generally good practice to follow is the pattern of “Red”, “Green”, “Refactor”. You can read more about it a previous post here.

Compositional Software

Making software in general is a rather big task, its so big that thinking of your solution as one big application is probably way too much to fit inside your head. So instead of thinking of it as one big application, think of it as a composition of many small applications. They are basically representing features in your larger application composition. Make them focused and keep them isolated from the rest of the “applications” in your composition. Keeping them in isolation enables you to actually perform changes to all the artefacts of the “application” without running the risk of breaking something else. All you need to do then is to compose it all together at the very top. Doing this you need to consider things like low coupling and high cohesion. Don’t take dependencies on other “applications”, keep all the artefacts of each tier close – don’t go separating out based on artificial technical boundaries such as “.. in this folders sits all my interfaces .. ” <- swap out interfaces with things like “controllers, views, viewModels, models”. If the artefact is relevant to your feature – keep it close, in the same folder. Nothing wrong with having HTML, CSS and JavaScript files in the same folder for the frontend part of your solution, in fact – nothing wrong having the relevant frontend code that runs on the server also sitting in the same folder. Partition vertically by feature and horizontally by tier instead and make your structure consistent throughout. All the tiers can have the same folders, named the same. If you have a concept and feature of “Documents”, that is the name of the folder in all tiers holding all the artefacts relevant for the tier in that folder for that feature.


It is by far so much easier to create new things rather than changing, fixing or adding to existing code, ask anyone that is or has maintained a legacy system without having the opportunity to do the rewrite. Software do have a tendency to rot which makes it harder and harder to maintain over time. I would argue that a lot of that has to do with how the software is written. Applying the principles mentioned in this post like SRPSOC, building compositions are all part of making this easier and actually make you for the most part create new things rather than having to fix too much of your old code. In fact, applying these principles you will find yourself for the most part just adding new things, rather than amending existing. This leads to more decoupled software, which is less prone to regressions.


By saying Sustainable Software Development, I mean software that will sustain in time and meet the following requirements:

  • Maintainable – spaghetti is not what you’re looking for. Apply practices such as the SOLID principles, decouple things. Make sure you identify the concerns in your software, separate these out. Identify cross cutting concerns, keep them in its own little jar and not bleed it through your entire app.
  • Changeable – Single Responsibility do in fact mean single, make the contracts explicit – you should be constantly changing your software, improving it – not just for new features or added value, but also when dealing with bugs – improve the quality of the system through refactoring.
  • Debuggable – Make your code debuggable, but not let the tool suck you in – use it wisely
  • Testable – Be sure to write code that is singled out on its responsibility, taking dependencies on contracts – making it possible to be focused and your tests small and focused

What I’m realising more and more from the work I do, there is no single magic bullet – there are many things that fit together and doing them together makes the bigger picture better. We’re often told when some new practice is introduced, it will be the magic bullet making all problems go away. They often fail to say that they were already doing a bunch of other practices that needs to be applied as well in order for it to be successful.

It is very important that we as developers focus on the important parts; deliver business value and deliver it so that we can change it when needed without sacrificing quality.

Applying the things in this blog post has proved to us that we get measurably less bugs, less regression, and it all boils down to the simple fact that we’re for the most part just developing new things. After all, focusing on single responsibility and separating things out and putting things in isolation leaves to creating new code all the time, rather than having to constantly just add yet another if/else here and there to accommodate change. Of course, there are much more to it than a post like this can ever capture, but its part of the core values that we believe in.

Bifrost up on Nuget

We are super excited, we finally managed to get Bifrost up on Nuget. We will be publishing packages as soon as we have changes, new features and such. We’ll get back to you on how we’re going to deal with versioning and what our strategies are for continuously deploying to Nuget will be. 

With our push to Nuget we added a QuickStart package that one can use to get up and running quickly, all you need to do after adding the package is to compile and run and you’ll have a simple sample that shows how Bifrost is setup and how you can get started writing your features.

Bifrost license change

The license for Bifrost used to be shared between Dolittle and Komplett  as a joint venture that began a couple of years ago. As our focus an investment is moving more and more into Bifrost, we have agreed with Komplett that Dolittle is taking ownership of the license and the project. With this we also want to simiplify the licensing, so we’re moving to a standard MIT license without any special clause like we used to have – plain vanilla.

So, what does this mean if you’re using Bifrost?

Well, nothing actually, it means that its a simpler model – there is one party that holds the copyright, no special clauses, a well known and well used license.


Touring south of California

In February I will be in south of California doing a couple of talks at different venus; 4 in total. 2 of them has been announced already here and here, when I get the links for the two remaining ones I will update this post with the details, so stay tuned. Thanks to Kim Schmidt from vNext_OC for making this happen and for asking me to drop by.

Basically the talks will be on two different topics.

Below you’ll see the different topics with the synopsis of them. So, if you’re nearby these venues, don’t hesitate to stop by. Also worth mentioning, Charles Petzold is giving talk at one of the user groups I’ll be doing a talk at, be sure to not miss it as well – more details can be found here.


Let’s focus on business value

Creating software is very hard, a lot of practices has been developed over the years to accommodate this and make it easier. Some of these are DDD (Domain Driven Design), SOLID, BDD (Behavior Driven Development) and concrete architectural patterns such as CQRS (Command Query Responsibility Segregation) and MVVM (Model View ViewModel) came as reactions to these practices. Einar will take you on a tour through all of the above mentioned subjects and show you concretely how you can achieve true developer productivity by applying all these. By utilising an open source framework called Bifrost, Einar will show end to end how these practices and patterns can come to life and can really let you as a developer hit the ground running and at the same time capture and deliver true business value without sacrificing code quality. All this and also cloud ready!

It’s primetime, a JavaScript story

It’s pretty fair to say that JavaScript is not a fad; it is by far
the most widespread programming language out there and also the most available runtime we have, ranging from toasters to the web, and even to the backend development through Node.js. Its probably also fair to say that we should really embrace it and start treating it like a first class citizen of our day
to day work. In this talk, Einar will take you on a tour of how you can work
with JavaScript with similar patterns you’re already used to from the rest of
your server code. Writing tests or specifications that proves your code is also
important, Einar will show how to get started with this and how you can achieve more testable JavaScript by applying patterns like MVVM (Model View ViewModel) using KnockoutJS

Singling things out…

I was at a client a while back and was given the task to asses their code and architecture and provide a report of whatever findings I had. The first thing that jumped out was that things did more than one thing, the second thing being things concerning itself with things it should not concern itself about. When reading my report, the client recognised what it said and wanted me to join in and show how to rectify things; in good spirit I said:


We approached one specific class and I remember breaking it down into what its responsibilities were and fleshed it all out into multiple classes with good naming telling exactly what it was supposed to do. When we were done after a couple of hours, the developer I sat with was very surprised and said something to the effect of; “.. so, single responsibility really means only one thing..”. Yes, it actually does. A class / type should have the responsibility for doing only one thing, likewise a method within that class should only do one thing. Then you might be asking; does that mean classes with only one methods in them. No, it means that the class should have one subject at a time and each and every method should only do work related to that subject and every method should just have the responsibility of solving one problem. Still, you might be wondering how to identify this.

Lets start with a simple example.

Say you have a system were you have Employees and each and every one of these have a WorkPosition related to it enabling a person to have different positions with the same employer (Yes, it is a real business case. :) ).

The employee could be something like this :

public class Employee
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

A fairly simple class representing an aggregate root.

Then go and add this other thing in our domain; a WorkPosition, a value type that refers to the aggregate:

public class WorkPosition
    public int Id { get; set; }
    public int EmployeeId { get; set; }
    public double PositionSize { get; set; }

One could argue these represent entities that you might want to get from a database and you might want to call them entities and DRY up your code, since they both have an Id:

public class Entity
    public int Id { get; set; }

public class Employee : Entity
    public string FirstName { get; set; }
    public string LastName { get; set; }

public class WorkPosition : Entity
    pubic int EmployeeId { get; set; }
    public double PositionSize { get; set; }

Nice, now we’ve dried it all up and the Id property can be reused.

The Id property is a classic pattern, but in domain driven design you would probably not use an integer as Id but rather a natural key that describes the aggregate better. For an Employee this could be the persons social security number. This means that an integer won’t do, but something that can tackle the needs of a social security number. For simplicity in this post, I’ll stick to primitives and do a string, normally I would introduce a domain concept for this; a type representing the concept instead of using generic primitives – more on that in another post.

We want to introduce this, but we’d love to keep the Entity base class, so we can stick common things into it, things like auditing maybe. But now we are changing the type of what identifies an Employee, and it’s not the same as for a WorkPosition; C# generics to the rescue:

public class Entity<T>
    public T Id { get; set; }
    public DateTime ModifiedAt { get; set; }
    public string ModifiedBy { get; set; }

public class Employee : Entity<string>
    public string FirstName { get; set; }
    public string LastName { get; set; }

public class WorkPosition : Entity
    public string EmployeeId { get; set; }
    public double PositionSize { get; set; }

Great, now we have a generic approach to it and get auditing all in one go.


We’ve just created a nightmare waiting to happen. We’ve made something generic, lost a lot from the domain already just to save typing in one property; Id (yeah I know, there are some auditing there – I’ll get back to that soon). We’ve lost completely what the intent of the Employees identification really is, which was a social security number. At least the name of the property should reflect that; Id doesn’t say anything about what kind of identification it is. A better solution would be going back to the original code and just make it a little bit more explicit:

public class Employee
    public string SocialSecurityNumber { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

public class WorkPosition
    public int Id { get; set; }
    public string SocialSecurityNumber { get; set; }
    public double PositionSize { get; set; }

That made it a lot more readable, we can see what is expected, and in fact we’ve also decoupled Employee and WorkPosition in one go – they weren’t coupled directly before, but the property named EmployeeId made a logical coupling between the two – which we might not need.

Another aspect of this would be bounded contexts; different representations of domain entities depending on the context they are in. In many cases an entity would even have different things that identifies it, depending on the context you’re in. Then Id would be a really bad name of a property and also having a generic representation of it would just make the whole thing so hard to read and understand. Normally what you would have is an underlying identifier that is shared amongst them, but you wouldn’t necessarily expose it in the different bounded contexts. Instead you would introduce a context map that would map from the concepts in the different bounded context to the underlying one.

Back to auditing – don’t we want to have that? Sure. But let’s think about that for a second. Auditing sounds like something you’d love to have for anything in a system, or in a particular bounded context, one could argue its cross cutting. It is a concern of every entity, but I would argue it is probably not something you need to show all over the place; in fact I’ll put forward the statement that auditing probably is an edge case when showing the entities on any dialog. So that means we probably don’t need them on the entities themselves, but rather make sure that we just get that information updated correctly in the database; this could be something we could do directly in the database as triggers or similar, or make sure everything goes through a well-defined common data context that can append this information. Then, for the edge cases were you need the auditing information, model only that and an auditing service of some kind that can get that information for the entities you need.

Fess up

Ok. So I have sinned, I’ve broken the Single Responsibility Principle myself many times, and I will guarantee you that I will break it in the future as well. In fact, let me show you code I wrote that I came across in Bifrost a few weeks back that got the hairs on my back rising, a system called EventStore:

public class EventStore : IEventStore
    public EventStore(IEventRepository eventRepository,
                      IEventStoreChangeManager eventStoreChangeManager,
                      IEventSubscriptionManager eventSubscriptionManager,
                      ILocalizer localizer)
        // Non vital code for this sample...

    public void Save(UncommittedEventStream eventsToSave)
            _eventStoreChangeManager.NotifyChanges(this, eventsToSave);

I’ve stripped away some parts that aren’t vital for this post, but the original class some 60 lines. But looking at the little code above tells me a couple of things:

  • Its doing more than one thing without having a name reflecting it should do that
  • The EventStore sounds like something that holds events, similar to a repository – but it deals with other things as well, so…
  • The API is wrong; it takes something that is uncommitted and it saves it – normally you’d expect a system to take something uncommitted and commit it

The solution to this particular problem was very simple. EventStore needed to do just what it promises to do in its name, all the other stuff is coordination and by the looks of it, it is coordinating streams of uncommitted events. So I introduced just that; UncommittedEventStreamCoordinator with a method of Commit() on it. Its job is then to coordinate the stuff we see above and the EventStore can then take on the real responsibility of dealing with storing things, and in fact I realised that the EventRepository could go at this point because I had tried to solve it all in a generic manner and realised that specialised EventStores for the different databases / storage types we support would be a lot better and not a lot of work to actually do.

Another thing the refactoring did for us was the ability to now turn of saving of events, but still get things published. By binding the IEventStore that we have to an implementation called NullEventStore – we don’t have to change any code, but it won’t save. Also what we also can do is to introduce the ability the EventStore itself to by asynchronous, we can then create something like AsyncEventStore that just chains back to the original EventStore, but does so asynchronously. All in all it adds more flexibility and readability.

Behaviors to the rescue

All good you might think, but how do you really figure out when to separate things out. I’ll be the first to admit, it can be hard sometimes, and also one of them things one can’t just be asked and necessarily be able to identify it within a heartbeat – sometimes it is a process getting to the result. But I would argue that thinking in behaviors makes it simpler, just for the simple fact that you can’t do two behaviors at the same time. Thinking from a testing perspective and going for BDD style testing with a gherkin (given, when, then) also gives this away more clearly; the second you write a specification that has and in it, you’re doing two things.

Why care?

Took a while getting to the why part. It is important to have the right motivation for wanting to do this. Single Responsibility Principle and Seperation of Concerns are principles that have saved me time and time again. It has helped me decouple my code and get my applications cleaner. Responsibility separated out gives you a great opportunity to get to Lego pieces that you can stitch together and really get to a better DRY model. It also makes testing easier, testing interaction between systems and more focused and simpler tests. Also, separating out the responsibility produces in my opinion simpler code in the systems as well, simpler means easier to read. Sure, it leaves a trail of more files / types, but applying proper naming and good structure, it should be a problem – rather a bonus. It is very different from procedural code, you can’t read a system start to finish – but I would argue you probably don’t want to that, it is in my opinion practically impossible to keep an entire system these days in your head. Instead one should practice focusing on smaller bits, make them specialised; great at doing one thing. Its so much better being great at one thing than do a half good job at many things.

Time for a debt management plan?

Lately I’ve been getting negative feedback from talking about technical debt. I’ve been trying to go over it in my head why it would be considered negative, and what spawns the idea of it being a negative thing. I really can’t figure out why it would ever be considered bad to have technical debt, so instead of trying to figure out why people would consider it a bad thing, I’ll try to shed some light on what technical debt in reality is.

I’m going to start off by saying; technical debt is something that all projects have, no matter how recent the project was created. In fact, I would probably argue we put in technical debt on a daily basis on all software projects. You might be screaming WAT at this point, and you’re fighting the urge to completely disregard this post and move long, because you think I’m talking utter nonsense. But before you do that, I’d like to take the time to lay out what i think classified as technical debt. 

// Todo

Ever sit in your code and you go up against something you really can’t fix, its too involved at the current point in time, or the architecture in its current state would not permit it, or plain and simple; you don’t have time – you’re having a Sprint demo in 1 hour. You end up putting a // Todo comment in the code, something to revisit at a later stage. You might not even know when. This falls into the technical debt category. One could even argue that any comment put into the code makes the code technical debt, the reason being – the code is too hard to understand on its own and needs a comment to explain what it is doing. I’ll leave the subject of general comments for now, as it should be subject of a different post.

Legacy code

Just about every system being built out there has some legacy they have to deal with, some data model that you can’t get rid of. The art of dealing with legacy code is then to try to come up with an anti corruption layer that will keep the legacy in one place. But even having this in place, sometimes things leak through. So things you really didn’t want in your new model might be leaking in, it could be anything from a simple property with the wrong name going through your new model to large concepts being misrepresented. All these can be categorised as technical debt.

Changing horses midstream

Working in software is in my opinion much like being on a high speed train that really don’t have a destination but have railway switches that makes the software change tracks. This can be new way of doing things that the team want to embrace. It could be new knowledge the team acquires that they didn’t have before that will make the software better moving forward. Everything being left behind at that point represent technical debt. They are things the team would ideally want to have fixed, but often in the interest of time, they can’t go and do it right now.


Another warning sign that makes my bells go off is when something is hard to follow. Unless you’re sending spaceships to the moon or other planets, I have a hard time believing that software should be hard to do, understand or follow. Done right, and everything should be very simple. Large methods, large classes, things taking on more than one responsibility, all these are things leading to complexity in the software and making it hard for anyone else but the guy that originally wrote it to understand. In fact, I would even argue that the guy that originally wrote it would have a hard time going back into own complex code. This is typically a situation were the team would like to have it another way, and hence should be categorised as technical debt. 


So, what about bugs then. This is funnily enough something that does not fall into the category. Bugs are defects in the software, functionality that does not work as promised. Sure, it could be a ripple effect thats causing the bug, or clash of bugs, based off other parts of the system being technical debt. But then you should try to identify the real problem and fix that in isolation, not categorise the bug as technical debt. 


Now what? 

Don’t jump into panic just yet, just because you’re realising the project you’re on seems to suffer from one or more of the above mentioned issues. How do we deal with it? Well, first of all – be honest. When it comes to software development and life in general, I’ve had great success with just being honest. Be honest with yourself, be honest with your team, be honest with whoever is picking up the bill at the end of the day; you have technical debt. And its fine, its actually a good thing, it means the system is evolving, you as a developer is evolving, and probably for the better. Its called progress. You only need to be aware of the technical debt, write it down somewhere – NOT IN THE CODE - somewhere making it visible for the entire team. Writing it down and glancing at it during planning, having it in the back of every developers mind makes it so much easier to actually deal with the debt, pay back some of it while moving forward and creating new features or fixing bugs. How you register it and make it visible is not important, whatever works for your team. Personally I prefer simple ways of dealing with this. One project I was on, we started by just putting the technical debt in the form of post-its on a wall. This slowly progressed into becoming a Trello board that we had running on a 42″ screen all the time. By doing this we had the technical debt available when not sitting in the office, but by putting it on the 42″ screen displaying only that made it a focal point. Something the team was focused around, all the time; keeping an eye on the debt – slowly paying back.

Another aspect I find important, not only for technical debt but in general; don’t make your code personal. Its not a manifestation of yourself, it is code. The code gets committed into the repository, and it is no longer yours, but the entire teams. The idea that you will be maintaining it for ever is just silly, you might quit your job, or worse things could happen. The code is not yours in that sense, you wrote it, but detach from it!

If for any reason technical debt is a loaded term in your organisation, you might want to consider calling it something else. Don’t pretend you don’t have the elements mentioned in your solution just because it is a loaded term. Call it something like “wall of shame”, or anything that will work within your team and organisation.



Stop letting technical debt scare you, stop trying to avoid admitting to the fact there is technical debt. We all have it, we all contribute to having it, the only important thing is that it is on our agenda, we need a way to pay it back. Establish your own debt management plan, either in the form of work items in your work item tracking software, post-its on a wall or something that fits you. Get it out there, in the open, its not scary – in fact, I would argue the opposite is scary; not knowing what the debt level is.

MCTS: Microsoft Silverlight 4 Development – Short book review

I’ve had the pleasure of getting early hands on for the MCTS certification guide for Silverlight 4, and figured I’d do a short review of it.



The purpose of the book is to give you a guide of what to expect to know for becoming a certified Silverlight developer. Personally I haven’t done the certification, so I won’t be able to say if it is sufficient or not, but I would imagine that the certification itself has been used as a guide for what is needed.

Silverlight 4 is a pretty large subject on its own, and quite ambitious to cover in just one book and at the same time provide guidance towards a certification. I feel that this book really accomplished this in a good manner, it is straight to the point but at the same time not leaving out any explanations. I even picked up some basic knowledge I was not aware of myself. 

Being a guidance for certification, it does just that, so its not going to go outside of that promise. Which probably makes it feel a little light-weight on real world scenarios and it stays true to the original Microsoft messaging. It mentioned MVVM to some extent, but it could probably have dove into that subject a bit more, in my opinion. But I totally understand why it is not brought up. Being very focused on code quality, testability and such I feel that it is important to get this message straight, even though it might not be 100% relevant to a certification. 

All in all I found the book to be as close to a page turner as these kind of books can be, I learned some basics myself and brushed up on my own knowledge of Silverlight while reading it. And I’m pretty confident it will serve as a good guide for a developer wanting to certify him/her-self as a Silverlight developer.


New blog – different focus

A couple of weeks ago, we started a new blog that you can find here. The focus over on that blog will be very different than I’ve been having on my own personal blog here. It will be more in the lines of our perspective on software development, what we think is important, values and how to do things. Not so much about specific technology, but rather techniques, processes, patterns and such.

I will still be blogging on this blog with different focus than on the DoLittle blog.

So, who are we

At the moment, we’re 4 happy chaps, doing software development and we share the passion of thinking we can always get better. The guys involved are as follows :

Pavneet Singh Saund - @pavsaund

Niclas Bergquist - @niclasbergquist

Michael Smith - @WolfieBhoy

Einar Ingebrigtsen - @einari

Without getting into very specifics about what we will be having a conversation on, we can say this much that we think have something interesting to say and hope you’ll be watching this.

Slashing away the hash bang in single-page applications in Bifrost

One of the things that has been discussed the last couple of years for single-page applications are how to deal with routing since rendering and composition in those kind of applications is being dealt with on the client. Many have been pointing to using the hash (#) as a technique since this is for one possible to use to change history in the browser without post-backing for browsers that does not have the new HTML5 history API. This works fine for applications and is very easy to respond to in the client, but the URLs become unfamiliar and looks a bit weird for deep-linking. In order for search crawlers to crawl content properly, a specification exist that also states the inclusion of a ! (bang) yielding a #! (hash bang) as the separator for the specific route.  In Bifrost we have been working quite a bit the last six months in order to get a model that we believe in for single-page applications. Many models build on relying partially on the server for rendering, but composing the rendered parts in the client. With Bifrost, we wanted a different model, we wanted everything to be based on regular static HTML files sitting on the server, without having any load on the server for rendering – just serve the files as is. Instead, we wanted to compose the application from files on the server. One of the challenges we wanted to crack was to have regular URLs without any # or #!, even for HTML4 browsers – or at least in any anchors linking inside the app. In order for this to work, you need to deal with requests coming to the server with routes that has no meaning for any server code running. One of the motivations were also to not have to do anything specific for any routes on the server, meaning that you wouldn’t need to configure anything for any new routes you wanted – everything should be done only once on the client.

The problem

The nature of a single-page application is that it basically has a start page, and all requests should go to this page. This page represents the composition of the application, it has enough information and scripts on it to be able to render the remainder of the app based on any URLs coming in. In order to accomplish this, the server must be able to take any URLs coming in and pretty much ignore the URL – unless of course there is something configured or a file exist at the specific URL. 


Our solution

Bifrost is for now built for .net and more specifically, so we had to dig into that platform specifically to figure out a way to deal with this. What we discovered is a part of the request pipeline in that we could hook into and do a rewrite of the path during a request. (The implementation can be found here.)

URL Flow


What about the client?

Another challenge is to deal with history without post-backing. The way we’ve built everything is that you as a developer or web designer does not have to think about wether or not this is a Bifrost app or just a regular HTML app, you just create your anchor tags as usual. Just create your links as before, no hash-bangs nothing special – have your full paths sit there. This also makes it work just great with search-engines and they will be able to crawl your content and get the proper deep-links and index you. But we need to hook into the browser still, so we don’t do a post-back to the server for any URL changes. The way we’ve chosen to deal with this is to hook into the body and deal with it through event-bubbling. Any click events occurring inside the document will then be captured and if it happens to be an anchor tag that is the source, we pull out the URL and rewrites history inside the browser. Since we’re using Baluptons History.js, we get support for HTML4 browsers as well. History.js will use hash in those scenarios were it can’t rewrite the path, but your URLs does not have to change – it will just use it internally and it will all be abstracted away.




Get every new post delivered to your Inbox.