The boy scout rule

Recently I had the discussion with a colleague on how new code was being added to a code-base without maintainability in mind. The discussion was sparked by a code-review that had been ping-ponging between the reviewer and the developer where readability and ( as a result ) maintainability was an issue.

The code review caught it this time, but this isn’t always the case. It boils down to mindset when approaching a given problem to begin with, especially when bug-fixing. Get in, fix the issue and get out with as little impact as possible. This is the so-called “fire-fighting mode” (other terms have been used, i.e. “task force” or “marine mode”) and is fundamentally the opposite of the “boy scout rule”. The boy scout rule’s best companion is the rule of “opportunistic refactoring”.

Here are some of my thoughts on the matter

Boy scout rule:

…Always check a module in cleaner than when you checked it out…. – Robert C. Martin

Opportunistic refactoring:

…any time someone sees some code that isn’t as clear as it should be, they should take the opportunity to fix it right there and then – or at least within a few minutes… – Martin Fowler

Cruft and technical debt build up over time or new requirements change the premise for what the code is attempting to solve. So when writing code many developers struggle with these rules, because they do not believe they are actually adding value. I think they believe that it’s often easier to just fix functionality in the quickest way possible rather than taking a step back to assess what the feature actually is attempting to solve. Many arguments excuses are used to justify not adhering these rules:

“But if it works, there’s no need to spend more time to improve the code”.

The code is in production, it has been tested by users and it works as desired. If you don’t need to change it, then I agree that refactoring just for the sake of refactoring might not be the best thing to spend time on. If you need to change or extend it though, what then? My basic thought is this: If you are afraid of changing it due to possible ripple effects, then that’s definitely reason enough to do more with it while you’re there already. You should NEVER be afraid of changing the code.

“Not my code, not my responsibility”

Too many have this attitude. The code-base is going to be developed and maintained by different people and it’s your responsibility to make it a good place to work in, day after day. In a way, it’s too bad we can see who committed what in the VCS (Version Control System). It leads to a blame-game and personal ownership (blame) of features. Maintaining the code-base is every team members responsibility.

“This wasn’t part of the estimates”

Estimation, agile and how we actually do are tasks are funny things that vary on a project by project basis. There are different understandings and requirements which play into the magic estimation number. The honest fact of the matter is that we usually know the most about a task the closer we are to actually starting on it. So if you estimated last week, and you’ve discovered something that drastically complicates the task, are your estimates still valid? Same goes with code and its complexity. This is something that arises when you are half way into solving an issue and you realise the need for a refactoring. It’s something you have to deal with and there is no time like the present. You’re already in there…fix it!

“We’ll create a technical task for this”

This could be the natural outcome of the previous point. When we discover code-wtfs that increase the planned scope there is a tendency to separate this into a separate task or story. This implies that we can deliver functionality in the “existing” way first, then if time allows do refactoring. What happens is by being “agile” the developer implements functionality, and doesn’t prioritise the refactor. Once the functionality task is marked as done and is tested, the “need” to refactor fades away. So at least we’ve marked the need to refactor in the backlog some place, right?

The right way to go about things is to do the needed refactoring as part of delivering functionality. There is no need for a separate technical task. You are doing what is required to deliver the needed functionality.

There will be times when the needed refactoring has large ramifications, and will actually have to be done as a separate task. This is something that has to be coordinated with the rest of the team, and at that point it is a group decision on the outcome.

“I can deliver more features faster, so that means I’m delivering business value!”

Business value is measured by many things. In the agile mindset there is an illusion that delivering business value means churning through the backlog as fast as possible without thought for the long-term maintainability. Though you may have high velocity in the beginning of a project, this will stagnate when change requests start ticking in. Which means a short delivery cycle, but a prolonged stabilisation / maintenance period. We have to write software that embraces change. Requirements always change after the user has started using the software.

Delivering business value also means delivering a maintainable solution.

Another approach is the spike and stabilise method, where you intentionally spike out code and allow changing requirements to form and adjust the end product. This also implies that the code you write will be overwritten and also maintainability will increase over time. This is usually a very conscious business decision. Not a developer-decision.

Wrapping things up

It’s not always as black and white as I’ve described above, but the points are valid nonetheless. I believe we as developers have a professional obligation to deliver business value through well-crafted code that captures the business requirements and allows for modifications to be made when change is required.

At the end of the day it comes down to our values as developers and how we want to define ourselves.

Tagged , , , ,

MVP Renewal 2014

The 1st of October was an exciting day at the office… Microsoft’s Most Valuable Professional (MVP) renewal day, and our resident MVP, Einar, was beside himself with excitement! But why the excitement? Well, the thing about being an MVP is that it’s something you’re nominated for and renewal is based on your last years contributions. These are evaluated in the deepest parts of the MVP-program at Redmond.

But before we move on… what exactly is an MVP? From the MVP-site:

Microsoft Most Valuable Professionals, or MVPs are exceptional community leaders who actively share their high-quality, real-world deep technical expertise with the community and with Microsoft. They are committed to helping others get the most out of their experience with Microsoft products and technologies.

So how’d it go with Einar? *drumroll*……..RENEWAL for the 7th year in a row! Check out his MVP-profile.

I asked Einar a few questions on the topic:

Congrats on the MVP renewal, how are you feeling right now?

Thanks mate, and thanks for taking the time to actually post about this. My feeling is awe actually – from seeing what awesome crowd I’m now part of. And I’m not going to lie, I’m relieved :). This time of year is always nervous, waiting to see if the mailbox holds an email with a note of renewal.

You’ve previously been a profiled Silverlight MVP, but seeing as that’s not around what’s your new expertise?

They retired the Silverlight competency last year and became Client Dev in October 2013. This year its been renamed and somewhat reorganized to be Windows Platform Development.

What are your thoughts on the Microsoft platform moving forward?

I really believe in the developer platform from Microsoft, always have believed in it. When it comes to the OS div or Office or similar, I really see that aspect as a bread-and-water business and something that is less relevant. These days I only use Windows for instance for hosting Visual Studio, the rest of my OS time is in OS X. But trying to not be religious about it. This is what works for me right now. There is another aspect that I hold dear to my hear; the cloud. Microsoft has really impressed in this area, Azure is really great. I’ve use some of the alternatives out there and Azure is in my opinion by far the best option for what we’re doing at least. The last aspect I want to bring up which is probably the thing that is the most important to me; open source. Microsoft has really matured in this space. In the last 10-15 years they’ve moved from seeing closed source as the only right approach to source opened to now fully open sourcing things and taking pull requests from anyone. This is a transformation that Microsoft is not getting enough credit for and seems to be escaping a lot of people.

Any final words?

Thanks! I’m going back to the roots more and more – community work is what its all about. When one has a passion, the experience of having it can become so much better if its shared. This is something I want to focus more and more on, user groups, blogging and more. Hoping for a renewal again next year.. :)

Once again, heartiest congratulations to Einar! Keep up the great work!

Tagged , , , , ,

NDC Oslo 2014 – Day 1

So, we’ve made our way to NDC Oslo with T-shirts and promo-cards for the occasion. It feels so good to meet up with old and new acquaintances and feel the vibe of just being here. Looking forward to be inspired!

The keynote by Luke Wroblewski really struck home, with focus on delivering a continuous user experience across devices. He also blew away the “myth” that mobile users actually are mobile. The fact that a large mobile usage actually happens from the sofa, at work & other locations we usually expect people to use desktop devices. It’s a recommended watch when the videos become available.



Bifrost and Proxy generation

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 doing this was also that we find types to be very helpful; and yes – JavaScript is a dynamic language but its not typeless, so we wanted the same usefulness that the types have been playing for our backend code in the frontend as well. The types represent a certain level of metadata and we leverage the types all through our system.

Anywho, the principle was simple; use .net reflection for the types we wanted represented in JavaScript and generate pretty much an exact copy of those types in corresponding namespaces in the client. Namespaces, although different between different aspects of the system come together with a convention mechanism built into Bifrost – this also being a post on its own that should be written :), enough with the digressions.

Basically, in the Core library we ended up introducing a CodeGeneration namespace – which holds the JavaScript constructs we needed to be able to generate the proxies we needed.


There are two key elements in this structure; CodeWriter and LanguageElement – the latter looking like this:

public interface ILanguageElement
    ILanguageElement Parent { get; set; }
    void AddChild(ILanguageElement element);
    void Write(ICodeWriter writer);

Almost everything sitting inside the JavaScript namespace are language elements of some kind – to some extent some of them being a bit more than just a simple language element, such as the Observable type we have which is a specialized element for KnockoutJS. Each element has the responsibility of writing themselves out, they know how they should look like – but elements aren’t responsible for doing things like ending an expression, such as semi-colons or similar. They are focused on their little piece of the puzzle and the generator will do the rest and make sure to a certain level that it is legal JavaScript.

The next part os as mentioned the CodeWriter:

public interface ICodeWriter
    void Indent();
    void Unindent();
    void WriteWithIndentation(string format, params object[] args);
    void Write(string format, params object[] args);
    void NewLine();

Very simple interface basically just dealing with indentation, writing and adding new lines.

In addition to the core framework for building the core structure, we’ve added quite a few helper methods in the form of extension methods to much easier generate common scenarios – plus at the same time provide a more fluent interface for putting it all together without having to have .Add() methods all over the place.

So if we dissect the code for generating the proxies for what we call queries in Bifrost (queries run against a datasource, typically a database):

public string Generate()
    var typesByNamespace = _typeDiscoverer.FindMultiple<IReadModel>().GroupBy(t => t.Namespace);
    var result = new StringBuilder();

    Namespace currentNamespace;
    Namespace globalRead = _codeGenerator.Namespace(Namespaces.READ);

    foreach (var @namespace in typesByNamespace)
        if (_configuration.NamespaceMapper.CanResolveToClient(@namespace.Key))
            currentNamespace = _codeGenerator.Namespace(_configuration.NamespaceMapper.GetClientNamespaceFrom(@namespace.Key));
            currentNamespace = globalRead;

        foreach (var type in @namespace)
            var name = type.Name.ToCamelCase();
                .WithType(t =>
                                .Variant("self", v => v.WithThis())
                                .Property("generatedFrom", p => p.WithString(type.FullName))
                                .WithPropertiesFrom(type, typeof(IReadModel)));
            currentNamespace.Content.Assign("readModelOf" + name.ToPascalCase())
                .WithType(t =>
                                .Variant("self", v => v.WithThis())
                                .Property("name", p => p.WithString(name))
                                .Property("generatedFrom", p => p.WithString(type.FullName))
                                .Property("readModelType", p => p.WithLiteral(currentNamespace.Name+"." + name))

        if (currentNamespace != globalRead)

    return result.ToString();

Thats all the code needed to get the proxies for all implementations of an interface called IQueryFor<>, it uses a subsystem in Bifrost called TypeDiscoverer that deals with all types in the running system.

Retrofitting behavior, after the fact..

Another discovery we’ve had is that we’re demanding more and more from our proxies – after they showed up, we grew fond of them right away and just want more info into them. For instance; in Bifrost we have Commands representing the behavior of the system using Bifrost, commands are therefor the main source of interaction with the system for users and we secure these and apply validation to them. Previously we instantiated a command in the client and asked the server for validation metadata for the command and got this applied. With the latest and greatest, all this information is now available on the proxy – which is a very natural place to have it. Validation and security are knockout extensions that can extend observable properties and our commands are full of observable properties. So we introduced a way to extend observable properties on commands with an interface for anyone wanting to add an extension to these properties:

public interface ICanExtendCommandProperty
 void Extend(Type commandType, string propertyName, Observable observable);

These are automatically discovered as with just about anything in Bifrost and hooked up.

The end result for a command with the validation extension is something like this:

Bifrost.namespace(&quot;Bifrost.QuickStart.Features.Employees&quot;, {
    registerEmployee : Bifrost.commands.Command.extend(function() {
        var self = this; = &quot;registerEmployee&quot;;
        this.generatedFrom = &quot;Bifrost.QuickStart.Domain.HumanResources.Employees.RegisterEmployee&quot;;
        this.socialSecurityNumber = ko.observable().extend({
            validation : {
                &quot;required&quot;: {
                    &quot;message&quot;:&quot;'{PropertyName}' must not be empty.&quot;
        this.firstName = ko.observable();
        this.lastName = ko.observable();

As I started with in this post; this has proven to be one the most helpful things we’ve put into Bifrost – it didn’t come without controversy though. We were met with some skepticism when we first started talking about, even with claims such as “… it would not add any value …”. Our conclusion is very very different; it really has added some true value. It enables us to get from the backend into the frontend much faster, more precise and with higher consistency than before. It has increased the quality of what we’re doing when delivering business value. This again is just something that helps the developers focus on delivering the most important thing; business value!

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 Scrum, eXtreme 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 SRP, SOC, 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.

Acceptance driven bugfixing

There’s a new task waiting for you in your inbox… a bug in production! Maybe the bug is completely unrelated to  code, you’ve created, but the report is there waiting for you. It’s critical, and has to be fixed “today” or “ASAP”! And with a number of consequences, like “this feature is vital!”, “support center is being called down by angry customers”, “we’re losing millions!”.

So given the levels of above chaos, you as a developer, have the power to put things right! Roll up your arms, it’s firefighting time.

  • Recreate the bug locally
  • Find and fix the offending code
  • Push and verify the code to production!
  • Voila! You just saved the day! Woohoo!

But wait…there are more bug reports ticking in…seems like you just broke some other vital part of the application. Ah well, there goes that pay-raise.

We’ve all had this happen to us at one time or another. We produce software that meets all the given business requirements, software that adheres to SOLID principles but somehow happens to contain a bug.

How to avoid that mistake?

Bugs are inevitable, no matter how methodical you are as a developer, or how thorough the product owner is, there will be aspects you’ve overlooked, or an edge-case that no-one has considered.

Well-defined tests are one of the better ways to document how any given part of an application works, especially if written as specifications. When you look at it this way, a bug is a certain part of the system that hasn’t been specified enough. The error could be bad user stories or bad implementation, but there’s a certain aspect that someone has missed. Following test-driven / test-first principles, the obvious solution is to find a test that’s missing some additional assertions, or introduce new tests that cover this aspect of the system. Either way, after this you should have red tests confirming the bug in the application. From this point in, it’s just the red-green-refactor mantra, and you’ve fixed the bug, hopefully improved the code a little and, most importantly, added more documentation for the next dev that needs to look at this code. Now you can feel a lot more confident when pushing the fix to production.

This approach has worked extremely well for me. As with the test-driven process, I often don’t know how to fix the buggy code, I just know that something in a given method is wrong, and I have a red test showing me what to fix. Giving yourself this harness also decreases the chances of adding “just another if” with unknown (long-term) consequences.

Now, imagine an entire team of devs working in bug-fix mode… how many new bugs are being introduced in the application if all you’re focused on is “getting that fix out”?

Tagged , ,

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&lt;T&gt;
    public T Id { get; set; }
    public DateTime ModifiedAt { get; set; }
    public string ModifiedBy { get; set; }

public class Employee : Entity&lt;string&gt;
    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.