How are you, Really?

“How are you?”

A simple question that usually is followed by a polite response expressing our contentment with our daily life situation. I’ve been answering it a little differently lately: “Not so good, really. I’m completely burnt out!”

People are taken aback by this brutal honesty and many don’t know how to respond. I don’t want to make things hard on them, but I can’t stand lying to others (and myself) anymore. Regardless of peoples responses, it’s been a relief to come out in the open.


3 weeks into my sick-leave and I was still struggling to get on terms with the matter. I couldn’t accept that this is happening to me. I couldn’t accept that I’m not well. I look fine, I’m healthy…there’s nothing physically wrong with me. But I can’t help but feel guilty for being at home. Guilty for not being at work and doing my part. Guilty for not being able to communicate properly with my wife and children. Guilty for not having the motivation to workout. Guilty for…everything really.

At this point I haven’t touched any apps on my iPhone. I haven’t touched my mac. I haven’t even been watching TV…


A week or so later and I’ve finally accepted my situation. It’s a relief. I finally see some hope. I’ve been speaking to a professional that has been through this before. He is honest, empathic and I feel an immediate connection. He speaks to me of his experiences, and I speak to him about mine. We dig at what’s been going on with me recently, and also not so recently.

We decide together with my employer that it would probably be a good move to visit the office without any work pressure. It seems terrifying… the women and men I work with every day, whom I know to be good people, my friends, scare me. Or rather I’m afraid of how that first meeting will be… the guilt starts creeping back. I decide to send a mail to everyone with a few words on the situation. This relieves a lot of tension…

Walking down the hallway, shaking a little, nervous I meet a colleague. He looks at me, smiles, embraces me with a hug and says its good to see me again. Tension & nervousness disappear. Guilt has gone and I can commence to meet the rest of the gang, and speak openly about my experiences. It’s a major relief to get passed that barrier. Now I can focus on finally getting back into the groove of things.

But, Why?

I have spent countless hours looking outwards to find the answers to what exactly the cause of this has been. Could it have been the project deadline before the summer? Or maybe the 2 years of trying to start a sustainable business (or two)? Or maybe the combination of young children and a wife suffering from illness? Maybe all of the above? I now see the tipping point clearly, the drop that caused the water to run over.

Pointing at events past and placing blame isn’t going to help me find my way back. It’s only upon looking inwards I have discovered the path to recovery. I must take care of myself in ways I haven’t done before. I have to be realistic with my expectations and priorities. I need to make time to reflect. I need to spend time planning and setting goals. I need to be honest with myself about my true feelings.

It’s now been 12 weeks. I’m back at work 50% of the time. I have learned things about myself I wasn’t aware of before. I am vulnerable, yet stronger than ever. I look forward to share some of my experiences and learnings in the time ahead.

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.

Acceptance driven bugfixing

I originally posted this on the dolittle blog.

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”?

Transitions pt.2 – a new beginning

This post is signalling an end to my time at Norwegian Broadcasting Corporation (NRK), even though it’s just a few months since I announced my career-move there. Before I go on about whats happening, I’d like to emphasise that NRK is a great place to be. I’ve met a lot of talented people and been exposed to a company culture that oozes of professionalism and encourages peoples creativity to flow.

That said, I’ve been given the opportunity to release the entrepreneur in me, and be part of creating something. During my time at Komplett, we created Bifrost, an open-sourced platform for application development. A bi-product of our efforts was a mindset towards application development and collaboration between team members that we found to be unique. Which is what has lead myself and Einar Ingebrigtsen to establish dolittle as a knowledge company.

We believe that writing code isn’t meant to be hard. It’s all about asking the right questions and getting the right answers in any given problem-domain. We believe Bifrost is part of the solution, allowing development teams to focus on the right problem; namely creating software that solves the needs of the end-user and the business.

Needless to say I’m excited about things moving forward, we see great potential in what we’re focusing on, and we’ll be keeping things up to date on the official dolittle blog.

I’d like to thank the people at NRK for the opportunity, and I hope to meet them again some time in the future.


As some of you may know, I’ve left the domain of scandinavian e-commerce and am no longer part of the web-team at Komplett Group.

My time at Komplett has been quite a ride; I’ve met some extremely skilled people, and worked on some really exciting stuff. Contrary to what some people might believe, the web-team is small and covers a lot of area. There was a lot of responsibilty and pressure, but also a lot of fun to be had. This has also allowed me to delve into several areas of software development that I couldn’t have on a larger team.

I now find myself neck deep within media / brodcasting production. To be more clear, I’m now part of the department for New Media at the Norwegian Broadcasting Corporation (NRK Nye Medier). Quite a large leap from e-commerce, but at the end of the day it’s all about delivering business value to the customer(s), and that’s something I’m getting the hang of :).

I’ve now started my commute to Oslo on a daily basis, and the team has welcomed me with open arms. They all seem thrilled to have me on board. It’s a good feeling, and I hope to find my role here, as I did at Komplett.

I like to think that it’s at Komplett I “found myself” as a developer. I’m looking forward to continue building upon my skills and continue my journey at NRK… :)

NDC 2012 : Impressions

Norwegian Developers Conference (NDC) is a the largest conference in Norway targeting the .NET community. It’s a 3 day conference with 2 days of workshops beforehand. The speaker line-up was also awesome, and the topics offer something for everyone.

I’ve had the opportunity of attending the conference and have had 3 intense days of learning, networking and eating… yea, lots of food.


This has been the first time I’ve attended a large conference of this kind, and I didn’t really know what to expect. I hoped to be wow’d by speakers and technology. Mainly I hoped to gain some insight and inspiration…. I had no idea!

I had initially thought to summarize each talk I attended, but quickly threw away that idea. So this is a write-up of the impressions I’m left with after NDC 2012. Hope you enjoy it.

What an opening

Aral Balkan pushed the boundaries this year and opened by performing the song “Pity the Child” from the musical Chess. This took us all by surprise and I was in awe; it was an awesome experience.

He moved on to emphasize the importance of our roles as developers. We are all designers of software experiences. Emphasizing the emotional reaction people have consciously and sub-consciously to the using our software. He moved on to describe the process involved in product design, and that this has to come from the top-down. It has to be something ingrained throughout the company itself, and effects ALL business decisions. Design and experience is NOT about pushing pixels and changing a color theme on your home page, it’s about commitment to your customers and a shared vision.

Truly inspiring, if you’re open to it… watch it here.

Decisions, Decisions

Dan North had a really challenging session on how software architecture is based on trade-offs. There are no absolute best practices when designing software, but there is a need to make conscious decisions based on the real needs.

He debated certain topics with the audience, or rather, he debated with himself, and the bored norwegian audience just sat and hoped someone else answered :)

Even though what Dan said isn’t new, it put things into perspective. He made some good arguments around Test-driven vs Test-first vs Test after.

The big take-away here for me was the concept of product half-time. How implementing features without tests / tests after could add more value. This, however, requires the developers to have an extremely solid grasp of how to write software, and structure the code in decent way. It doesn’t give you the right to write crappy code.

Code Ninjas

I went to the talk from Hadi Hariri named “Developers: The Prima Donnas of the 21st Century“, expecting a face-slap or a wake-up call of some kind, and behold…. *SLAP*!

Hadi had an awesome rant on what the software industry has become, and how developers put themselves on a pedestal above others. How we don’t know how to engage in customer communication, and expect people to understand our technical jargon.

At the end of the day, we don’t make software to have flame-wars on what technology to use, but to delivery good, working software to the end-user.

Also, I sat on the front row, and was addressed to as an Australian (something to do with whom I was sitting between).

Loved this session and recommend it to EVERYONE.


Billy Hollis had a couple of great talks on user experience. The first was about thinking outside the box. The time for features only is gone. Now the users expect features, but leveraged in an extremely easy to use way.
Billy took what Aral mentioned in his keynote and dove into theory and gave suggestions about how to take this back into the wild.

In his storyboarding talk, Billy emphasized the need to have lots of ideas or prototypes, and to not become attached to them. He showed some techniques and alternatives, and strongly suggested using paper / pencils for your creativity sessions. This reminded me so much about John Cleese’s talk about creativity.

He also made me promise to try storyboarding at home… I’ll save that for another blog post :)


To me, this conference has confirmed a lot of things I’ve been thinking and doing. It’s reinforced the fact that we, as developers, have to think about the user, even when “the business” gives us a defined user story / layout. It’s our job to say ‘no’, when people force us to remake the same old crap.

I’d also like to say that there’s a ton of other talks I loved from Robert C. Martin, Venkat Subramaniam, Jimmy Bogard, Damian Edwards… . Not to mentioned those talks I have yet to see.

I’m inspired, I’m eager and I’m ready to focus on what’s important.

NDC 2012 Giveaway @ NNUG Vestfold Meetup 9. May

That’s right! Thanks to the folks at Programutvikling, we’re going to be giving away a ticket to NDC 2012 at the next NNUG Vestfold meetup!

There’s gonna be frontend focus this meeting. I’ll be warming up the crowd with a session on “Forseti Driven Development”, and the main show is gonna be Marius Gundersen presenting “Building a 3D engine in Html5”.

More info on the talks, and the speakers on the meetup page.

Looking forward to it :)

Spread the word!