Wednesday, 9 October 2019

Class Name Suffix Wheel Of Fortune

Hey developer!

Do you find it hard to name your classes?

Perhaps you have a seemingly large number of services, or helpers. Not everything can be a service or a helper right?

If this is a problem you can relate to, then I have the ultimate tool for you!

The Class Name Suffix Wheel Of Fortune

Just spin the wheel, and you'll never need to worry about your class name suffix ever again!

ps. Once you're done having fun, go learn some software architecture to avoid these useless suffixes in your code :)

Tuesday, 10 September 2019

Good Help Is Hard To Find - Tips When Hiring Remote People

Good Help Is Hard To Find.

This is the eighth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology.


Are you hiring remote developers? Your decision to do this might be due to cost (to save money), due to local skills shortage, or when you absolutely must hire a specific person and are willing to let them work remotely.

When hiring remote staff members, you need to keep in mind that it will not be as smooth as you might think. Humans are fascinating when you put them in different scenarios, and some people who were fine to work with in an office might not cope well when isolated.

In this article I will present a few of the challenges I tackled when dealing with remote staff members.



Remote staff members are isolated. They miss out on important information. They are not privy to cross-desk small-talk and banter. They definitely are not able to go for lunch with people. We all need the company of other humans.

You really need to figure out ways which you can help your remote staff feel like they have real human contact.

Limited Communication

In a physical office situation, staff members will interact at some point during the day. When you have remote people, this does not happen. Most of the time you only have the remote people interacting with their current project team, and sometimes just at a daily scrum. This is not much communication, and many people might not get the information they need to do well in their jobs without those extra office side-chats.

Quality & Performance 

When developers help each other then they will come to a consensus with their approach. They come to a solution more quickly, and there will be less bugs. The opposite is often the case when it comes to isolated developers.

In my experience, remote people are far less likely to ask for help. This has a knock-on effect of their quality potentially going down, as well as their speed.

Second Class Citizens

It's very easy to get in a habit of treating remote people 2nd class citizens. I have seen this in various companies, and decided very early that we must replicate in-office communication as closely as possible.

Tips to Improve Communication


Have you ever joined voice-only conference calls. They really suck. They really do!

Being able to see a person's face is very important. It makes the calls quicker and more efficient, while also giving you all a more human interaction. Slack conversations and email have their place, however they can take way too long. So I favour video as much as possible.

Tip: My top tip is to use always use video for all meetings and discussions. There are plenty of tools out there. Zoom is my preferred choice. There are other good options such as Slack video, and Google Hangouts.

Frequent Rituals

My most distributed team consisted of 2 offices and 4 remote developers spread across 3 countries. Very early on, I introduced daily all-dev standup where devs would talk about what they were doing, and would ask for help if required. Arguably, this might not significantly serve the projects in the short term. However, the interactions each morning did facilitate knowledge sharing across all devs. It was a great start to the day, and I personally really enjoyed the feeling of seeing everyone each day.

Tip: Strive for some sort of group interaction which can mimic a physical office environment. Make it frequent, and at least once per week.

Encourage Remote Questions

Remote developers do not have much interaction during the day when compared to developers who were sitting at the same desk.

I encouraged developers to avoid asking questions of people who were physically in the room. I told them to ask the remote developers were possible, as it would encourage them to do the same.

This dramatically increased the amount of communication. While this might sound a little inefficient at first, in the long term the communication tightened up, and video questions became the norm. Quality of work and happiness of remote developers increased as a result.


When I started to take on remote staff I insisted that they come to the office as often as possible. For people in the UK it was around once per month for a couple days, people in other countries around once a quarter. This is obviously an extra cost to the company, however the improvements in team bonding and efficiency are totally worth it.

Tip: Get your remote staff to visit the office as often as possible.

Final Thoughts

The world is modernising where people can work from anywhere. You need to be extra diligent when it comes to care for these staff members, as you can't actually see their physical conditions, and you have far less contact with them.

Video calls are critical in helping people feel less isolated, and you must develop daily and weekly rituals to keep the remote people engaged and in the loop. Encourage your office staff to engage frequently with the remote staff, and definitely try to have your remote staff travel to physically engage with everyone else.

I hope you found this article helpful.

Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Digital Producers
  8. Tips When Hiring Remote People
  9. Tips To Improve Developer Retention (coming soon)
  10. Tips When Hiring Lead Developers (coming soon)

Saturday, 7 September 2019

Billing - A Better Alternative


When I was Head Of Development at The Cogworks we originally tried to bill by the 1/4 hour. It was insanely granular and cause many undesirable side effects and habits. Even if we rounded up numbers to meet 7hrs per day, it seemed that projects were just not profitable. It was quite hard to get my head around it, but much of this was because linking estimations to "time spent" to "billing" was causing many assumptions about workflow which were just wrong.

For example, we all should know by now that 1 dev working solidly for 7hrs is more productive than the same dev trying to work on different 1hr tasks. Nothing ever takes an hour. Downloading a code repo & getting it running could easily eat up 1 hour. Super granular estimates were linked to granular timesheets and billing which never accounted for context switching. So on paper we were always going "over budget". Crazy right?! I still find this hard to think about, as it does seem counter intuitive. Basically, when you context switch, there is a significant amount of time you need to waste on gaining speed. Kind of like a car being stopped at every traffic light.

A Simple Elegant Billing Model

  • 0.5 to 1 day billing increments
    • Use this for items which are estimated to be around an hour to several days
    • Even if an item is "estimated" as trivial (perhaps 1-2hrs), just charge 1/2 day
  • 1 - 2 week "project team" billing increments 
    • Use this for chunks of work which is estimated to be weeks to months long
    • A team may consist of 2 devs, Producer, Designer and QA
  • Emergency tickets are pre-sold at 2/3 day billing increments
    • This is essentially prepaying for disruption
    • Gives you the ability to ask the client "do you want to use your pre-bought ticket" or is this ok to just schedule into support & maintenance?
    • Tickets expire after 3 months if not used

This billing model free's up your developers from the shackles of timesheets, and also builds in adequate buffer for all those random project comms and meetings. When I introduced this at the Cogworks, it was as if a burden had been removed from day to day life. Everyone was happier.

Friday, 6 September 2019

Stop Using Timesheets


In an organisation which does software development, timesheets can really damage your productivity for what is actually a false economy. As Head of Development at The Cogworks I saw all of these problems and eventually abolished them completely.

In this article I will debunk common reasons for requiring developers to do timesheets. I will give better alternatives which will make your workforce happier and the organisation more profitable.

Comparing Projects For Efficiency

I cant believe I even need to state any of this, but here we go...

No two projects are the same. When I was at The Cogworks, we helped a client launch 100's of websites using a standardised multi-lingual starter-kit, "virtually identical" Information Architecture, and "very similar" designs. Each project was totally unpredictable in delivery due to changed in content, varying client-side interaction times, different developers, different designers, different devops people on the client side, and secret stakeholders who appear at the 11th hour. Keep in mind, this was the same client!!!

Requirements will always differ in some way, and stakeholders and client-side Project Managers change even within the same client & during a project. I have seen a project be totally derailed because a new (not so great) PM appeared on the client-side.

There is no point trying to compare build & deploy time for even small items. No two pages will ever be identical. I commonly hear "It's identical except...".

People on two project teams will have differing skills, experience, knowledge, personalities, and experience working with each other. Imagine taking a team who get along and have created many projects, however they are a bit sloppy. Compare that group to a team who have new members who don't know each other's skills and personalities, however they are all very capable.

I hope I have convinced you to stop trying to compare projects.

There are however other ways to tell if a project was efficient. For example, count the number of calendar weeks that the project took to complete. This is not the same as the number of utilised hours!

Performance Reviews

Using timesheets for performance reviews makes absolutely no sense. As a manager I want to know how many tasks a dev can do, and how often bugs are reported by QA.

I'll give you this (really bad Apples & Oranges) example:

Time logged is not the same as output
Anthony is a great at baking, however he worked on task "Apple Sauce" for 4 days. 
Greg is a great at Apple Sauce, however he worked on task "Orange Meringue" for 3 days. 

These people worked on things which they were not specialised in. How can you compare their time?

An alternative is to track output, not time logged. Track the number of tasks which each developer does. A very simple metric is to count the number of Jira/Trello/Asana/etc. cards which are completed within a timeframe.

Anthony's Apple Sauce is horribly overcooked with over-caramelised parts.
Greg's Orange Meringue has less perceivable defects than Anthony, however he didn't need to use a stove.

These tasks were totally different. Anthony basically failed at his task. How do you compare them based on timesheets?

An alternative is to track the number defects which are flagged. If you are using a Kanban process, then you can simply count the number of defect cards which are created against the work items.

Other Issues
No one knows if either tasks are complete, or even if they are done to the satisfaction of the client. Did the client report any issues, did QA find issues? 


Timesheets are seldom accurate. Here are some common habits of someone who fills in timesheets. I can absolutely say that these things happen because I personally have done all of these, and will continue with these habits if made to do timesheets.
  • Round up numbers to get 8 hours tracked per day
  • Add a number to a random client which I "think" I worked on
  • Forgetting to do them on Monday, so I do them from memory on Tuesday
  • Forgetting to do them all week, so I do them from memory on Friday
  • Forgetting to do them all month, so I do them from memory on when I am chased
    • Yes I've done this one too!

Even automated tracking will still be wrong...

Think about toilet breaks, coffee breaks, discussion at the water cooler, cigarette breaks, impromptu project chats, emergency meetings, helping another developer, doing a quick code review, phone calls, emails, Slack, calendar, Trello, and finally... short lunch vs long lunch. Trying to account for all these scenarios is a fantasy fallacy of micromanagement.

But I hear you saying "what about mouse tracking software?". Well, stop reading this article. If I cant convince you then perhaps these people can:

Client Billing

Fixed Cost Billing

I have been part of countless projects where I was required to do timesheets because they were apparently used to bill the client. When I found out that the projects were all fixed cost, I asked the question: "If the project is fixed cost, then how are the timesheets used to bill the client?"

The answer was: "The timesheets are used to see if we're losing money".

*face palm*

Tracking project time is different to tracking people time. I'll explain more in a future post.

Billing For Time Spent

If you are using timesheets to do client billing, then you are probably being too granular.

What would you do in this following scenario?
Developers help each other with questions, code reviews, discussions, architecture. Very often the knowledge / skills required may not exist within the same project team, so developer from another team is asked for some quick help. Very often this will be just 5 minutes. Sometimes it is longer.

Also, what about all the project meetings? eg. Standups (3-15mins), sprint planning, sprint review, sprint retrospective, random comms, emails, quick chats with the PM, 2min slack conversation with the client devs. What about when a colleague asks "How was your weekend"?

I know what you're thinking...
1. Dev 2 should enter a number into their timesheet that they spent 5mins helping Dev 1
2. As long as a developer's time is tracked against a client/project then there is no money loss.

Why are you concerned about tracking developer time by the minute? This is classic micromanagement! There is not value to the business to know that a developer asked another developer a question. It is wasteful. People hate and resent this level of micromanagement. Developers help each other and it all evens out anyway. So stop trying to track this!

A better alternative is to take a higher level approach. Bill by the day, week, sprint, month etc. See here for a better alternative.

Final Thoughts

I hope I have given you food for thought when it comes to timesheets and your production team. Comparing timesheets of projects has absolutely no value. Performance reviews should be based on quality and quantity of output, not time logged. Accuracy of timesheets is also generally crappy. If you can change your billing process to be less granular, then you will not need timesheets.

Once you remove timesheets from your business, your staff will be more productive and happy.

Wednesday, 24 July 2019

Azure Naming Conventions

I have gone back and forth with Azure naming conventions over the years. There are various trade offs to consider, but I think I have settled on a format... for now.

I prefer to see the resource type as a prefix, while the environment (dev, qa, uat, prod) as a suffix. In the middle, I like to see the purpose of the resource.

So my format is:

What: The resource type
Why: The purpose / project
Where: The environment (eg. dev, qa, uat, prod)

This naming convention allows me to see all the resources ordered by their type (eg. sql for SQL Server). In the following example, I can visually scan for "sql"

Notice that this allows all the sql resources to be grouped by project name. Using the suffix, I can then easily see the environments related to those projects.

In the examples below, the I use "nicename" for the "purpose".


General rules:
  • All resources (including resource groups) are lower case
  • Where hyphens are not permitted, simply omit them. eg. storagenicenameprod 
  • Use industry accepted abbreviations (eg. vnet, app, net)
  • Where there is no widely accepted short abbreviation, use full words (eg. search for Azure Search)
  • Where character limits are imposed, fall back to acronyms (last resort as this is harder to understand)

Resources groups

For example:

The reason I have separated web, data and network related resources is because putting all resources in a "production" group could get very messy. The separation allows for the types of functionality (within an environment) to be grouped nicely.

Data Group - Data / storage related
  • Database server
  • Blob Storage
  • Table Storage
  • Azure Search 

Net Group - Network, Security and Protocol related
  • Virtual Network
  • Network Security Group
  • Application Gateway
  • Azure Front Door
  • Load Balancer

Web Group - Web App & Content Delivery related

  • App Service Plans & App Services
  • Functions
  • Sendgrid

Resources In General

<resource type>-<purpose>-<environment>


The reason I like the resource type first is because I often look at the entire resource list, so (for me) it is helpful to put the resource type at the start of the name. Yes I know that you can order by resource type, however there is something I personally don't like about that.

App Service Plans


Example Resource Group: rg-web-prod

App Services


Example Resource Group: rg-web-prod

SQL Database Server



Example Resource Group: rg-data-prod




Example Resource Group: rg-data-prod

Azure Search 



Example Resource Group: rg-data-prod

Virtual Networks


Networking is an interesting exception, as I prefer to take a numbering approach at network levels. This is because networks can be used for all types of purposes. I also like to keep the network dependencies together. So I will prefix the Network Security Group (nsg) with the name of the the vnet.


Example Resource Group: rg-net-prod

Network Security Group's related to a VNet should follow the pattern:


Example Resource Group: rg-net-prod

In this example the "purpose" is to attach a Network Security Group to the Vnet for the Application Gateway and Azure Frontdoor

Application Gateways



Final Thoughts

Naming things is a balancing act which I (and many) struggle with. Something that you are happy with might start annoying you years later. What ever you choose, try to ensure that your naming is understandable, consistent, and easy on the eyes.

Also, keep in mind that you probably won't like your naming convention in the future :)

Friday, 28 June 2019

Estimating - There is no such thing as a 1 hour task


Estimations in software development have always been a problem. Many teams and organisations struggle with finding the right way to do estimations. There is no right answer, and it really depends on your organisation. 

If you are measuring by the hour, then perhaps you have struggled with understanding why you are not as profitable as you could be. This may arise from the fact that your lower estimates are just not realistic. I will explain what I mean in the following examples.

In these scenarios we assume that the developer deploys to an environment, then confirms that the functionality works before handing it to a QA/UAT person.

Example 1 - The perfect case (no defects or problems)

In this example I will outline a 1hr task in a "best case" scenario which has no defects or problems. The order of events will differ depending on your processes. 
  1. Download repository & get code running locally - up to 0.25hrs
  2. Do the work - 1hr 
  3. Deploy to a development environment & test (0.25hrs)
  4. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
  5. Deploy to a QA environment & test (0.25hrs)
  6. Tag & cut the release (0.125hrs)
  7. Deploy to a UAT environment & test (0.25hrs)
  8. Deploy to production environment, put live, then quickly smoke test (0.5)

As you can see, a single 1hr task can actually take 3hrs in a good scenario. This does not even factor in the time of the QA or UAT people. Also, the context switching of doing all these different steps is a significant time drain.  

You are thinking that many tasks together can be bundled, so we would save time on deployments. As you will see in the next example, the math still does not work out.

Example 2 - The perfect case (no defects or problems) with multiple work items

In this example I will outline 5x 1hr tasks in a "best case" scenario which has no defects or problems. 
    1. Download repository & get code running locally - up to 0.25hrs
    2. Do the work - 5x 1hr 
    3. Deploy to a development environment & test (0.5hrs)
    4. Commit code, create pull request, & participate in the code review (5x 0.25 x 2 devs = 1.25hrs) - Note: each task has it's own code review
    5. Deploy to a QA environment & test (0.5hrs)
    6. Tag & cut the release (0.125hrs)
    7. Deploy to a UAT environment & test (0.5hrs)
    8. Deploy to production environment, put live, then quickly smoke test (0.75)
    As you can see, 5x 1hr tasks can actually take 9hrs in a good scenario. We are not really saving much time by bundling. On average, our  1hr tasks are actually taking almost 2hrs per task.

    Example 3 - The bad case (defects & problems)

    In this example I will outline a 1hr task in a "bad case" scenario which has defects and problems. 
    1. Download repository & get code running locally - up to 0.5hrs
    2. Do the work - 1hr 
    3. Deploy to a development environment & test (0.25hrs)
    4. Code does not work. GOTO step 2
    5. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
    6. Code is rejected. GOTO step 2
    7. Deploy to a QA environment & test (0.25hrs)
    8. Fails QA. GOTO step 2
    9. Tag & cut the release (0.125hrs)
    10. Deploy to a UAT environment & test (0.25hrs)
    11. Fails UAT. GOTO step 2
    12. Deploy to production environment, put live, then quickly smoke test (0.5)
    I hope my following calculations are correct...
    0.5 + 
    1 + 0.25 +
    1 + 0.25 + 0.5 +
    1 + 0.25 + 0.5 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 + 0.5
    = over 12hrs

    It is important to note that this is a really bad scenario. Something has gone wrong at every part of the process. Failing Code Review and QA and UAT should be very rare. However failing at least one Code Review or QA or UAT is quite common, and should be expected.

    Programming is very difficult. So the reality of bugs/issues falls somewhere between the ideal (no defects or problems), and the bad (has issues at all stages).

    It is also important to note that unknown obstacles pop up which a developer must address. For example, any frontend developer will know about versioning/dependency issues with their tooling. I have never met a seasoned .net backend developer who has not yelled at the top of your lungs when they realised a Windows update has broken something.

    Final Thoughts

    In reality there is no such thing as a 1hr task. Even the most ideal scenario has parts of the process which are not accounted for, which can easily push the real time spent to 3hrs. Even bundling items together does not effectively eliminate this reality. 

    Programming is hard, and there is no such thing as bug-free software. A release with multiple tasks will have at least one item which is rejected at Code Review, QA, or UAT. Good processes only mitigate defects and problems. 

    I hope that this article has given some insight in what it is like to estimate effort in hours. There is no such thing as a 1hr task. What ever your estimation strategy, you need to account for this reality so you can stay profitable.

    Sunday, 9 June 2019

    Umbraco Codegarden - Moving to dotnet core

    A little over 2 weeks ago I ran an open circle which was aimed at getting Umbraco transitioned to dotnet core. The discussion group centred around what the community can do to help speed up the transition.

    Umbraco's Current Structure

    As it stands, the current Umbraco solution structure looks like this:

    Umbraco's Future Structure

    Moving forward, the proposed solution structure will look something like this:

    Note: The new solution structure will be maintained in a separate branch. The rationale is that the changes required to get there will create many frequent breaking changes.

    Community Tasks

    The stages to reach the proposed structure will require significant refactoring. There are various tasks which are simply too complex (with too many interdependencies) for non-HQ people to accomplish. However, we managed to pull out specific tasks which are isolated enough for the community to have a go with.

    I have created issues on the Umbraco issue tracker for these items:

    Requiring Discussion

    A more complicated issue arose from the discussion around how Umbraco does imaging. Namely, how do we abstract that functionality? 

    Shannon suggested to create an RFC so it can be discussed:


    Final Thoughts

    Dotnet core 3.0 is coming out at the end of the year (November?). Umbraco realistically needs to wait until at least this time before it can investigate MVC related refactoring. In the mean time, there is a huge amount of refactoring to do. The items in this article are available to the community, and are just the first wave of refactoring which is required.