Unit Testing – Check your Return on Investment

I once asked a team to question everything we do. We ended up with a few suggestions about things we could streamline but I was surprised at how quickly everyone on the team said “unit tests are good”.

Are unit tests good?

I’m strongly believe that unit tests are critical, but only if they offer a good return on investment. It takes a scary amount of time writing and maintaining a suite of unit tests, so any efficiency savings can really add up.

Why are you spending time and money writing and maintaining unit tests that are trivial?

Adam Tibi got me thinking about it a lot recently when I read his post on not testing MVC controllers.

When are unit tests “Bad”

I basically agree with Adam, but applied to every single line of code, not just controllers.

I’ve seen teams decide a certain % of code coverage is required and then just mechanically write test upon test until that magic number is hit. What’s the point of unit testing something like a simple wrapper that passes through to another layer. What have you achieved?

I find questioning the ROI of a unit test can also lead to some nice refactoring.

Summary

Question your return on investment of every unit test you write and maintain. Why are you spending time and money writing and maintaining unit tests that are trivial.

If the unit test is pointless, mark the code under test with some sort of “ExcludeFromCodeCoverage” attribute and spend your time, and money, on more important things.

Convert unix epoch time to DateTime in C#

I recently had to convert unix epoch time to DateTime and like the rest of the world turned to stackoverflow. The top answer is a very simple solution of adding the unix time, which is in milliseconds, to a DateTime of 1/1/1970.

Nothing wrong with that, but it turns out it was added into DateTimeOffset in .NET 4.6:

static DateTimeOffset FromUnixTimeSeconds(long seconds)
static DateTimeOffset FromUnixTimeMilliseconds(long milliseconds)
long DateTimeOffset.ToUnixTimeSeconds()
long DateTimeOffset.ToUnixTimeMilliseconds()

So now you can do something like:

var dateTimeOffset = DateTimeOffset.FromUnixTimeMilliseconds(1454049938871);
var dateTime = dateTimeOffset.DateTime;
Console.WriteLine($"The time is {dateTime}");     // The time is 29/01/2016 06:45:38

I can’t imagine it will make a massive difference to your application whichever way you choose, but I think it’s really good that little things like this are still being added to the framework after all this time.

Further Reading

If you’re really interested, you can look at the /source and see it’s pretty much the same thing, but I imagine it’s slightly more efficient. I guess you could do some metrics, but if converting to and from unix time is the bottleneck in your application I envy you!

Who owns impediments?

In a previous post I listed some of the different types of impediment to identify as a scrum master. In this post I’m going to go through the same types and list who I think should own them and some ideas of how to try and remove them.

Types of Impediment

Different Types of Impediment to Identify
Different Types of Impediment to Identify

In the same order of smallest scope, all the way out to the whole organisation.

Technical Impediment

Some organisations I’ve worked with make it the responsibility of the team member to raise support requests to get things like “my monitor is broke” resolved, but I think that’s a mistake. Sorting out issues (or going to PC World to buy parts) is a waste of team members time. The scrum master as “general dogsbody” should be solving this.

In the meantime, is there another machine to use because someone is on holiday, ill or in a meeting? Could they pair with someone? Basically, don’t treat broken equipment as dead time.

Team Member Impediments

Again, ignoring personal issues (they might be a HR problem), these types of impediment fall squarely on the individual.

I’m a strong believer in treating people like adults, so although it may not be their fault they are not familiar with a technology – that’s an organisational issue in resourcing – they now need to become productive.

It’s the Scrum Masters job to help with that in any way they can, say putting them in touch with the company SME or other training resource, but ultimately the individual has to put the work in.

Technology Impediment

I believe the team should prove to themselves that changing the technology is worthwhile. Once they are convinced, getting buy in the from the product owner and stakeholders to complete technical stories and not add business value should be easier.

Using the example from the previous post of upgrading from EF5 to EF6, ask 1 person to come up with a business case detailing the return on investment of performing the upgrade. It’s a balance between how long the upgrade will take, including roll out to production environments vs how much time it will save in the future.

If there’s 2 weeks left on the project, it’s going to take 5 days to upgrade and save 1 day it’s not worth it!

Process Impediment

If you do have a vocal member of the team telling you something is lacking, I would use this opportunity to try and coach them to become solution orientated. I’d task that person to take ownership and come up with a solution but provide lots of assurance that if they’re solution doesn’t work it’s not a problem.

Team Impediment

These types of impediment can be very hard to solve and unfortunately the ownership falls on the scrum master.

If you are unfortunate enough to have a “bad egg” and you’re inexperienced with dealing with these types of issue I recommend you speak to your HR department for advice. If that’s not possible, seek advice from someone who does.

Organisational

The Scrum Master Podcast calls this “the dreaded system”. I imagine they’ve used the word “dreaded” because changing the system you work in can be almost impossible.

Ownership again lives with the Scrum Master, not to solve them, but to try and isolate the team from them. I find a great exercise to help with this is Circles and Soups retrospective.

Summary

Not all impediments are the scrum masters to solve, sometimes it can be really beneficial to pass ownership to a team member.

This obviously isn’t an exhaustive list and I’m not going to claim it’s perfect, so please leave a comment below or catch me on twitter if you have any comments.