The Psychology Of Software Development Part 2. Building Premier League Quality Software Teams

In this series I wanted to offer the posts in somewhat of a chronological order of the cycle that most software developers and companies will go through when looking for a new employer/employee partnership. 

Following on from my take on phone interviews, I want to offer an insight into something that i'm pretty passionate about, something that employers should think about before any face to face interview, especially when putting together new teams; I want to take a look at how you build a truly successful software development team. 

I've been thinking about an analogy around this for a while and I can't get out of my head the concept of software teams, much like football teams (or any sports teams), have various styles of players, or in our case; various styles of developers. 

I came to this conclusions because, my overriding skills lie in leading software projects and getting applications to market. I say this with some modesty, being good at this and focusing on these skills will always come at a detriment to other aspects that may be desirable within a successful team.

So what comprises a good software development team? What compromises a good team in any situation? Well, we could mention collaboration, teamwork, communication, understanding? But all of these things only really come into play once the team is together. 

The core basis of any team is balance, each position that's supposed to be filled is filled. No matter how exciting a football team with 11 strikers sounds, you'll never find a team that plays it, and it's obvious why, right? What happens when the other guys head down your end? Your strikers can't tackle, they give away penalties and free kicks get carded and before long you're down to 8 men on the pitch because you've put them into a position that doesn't naturally suit them and invariably they haven't trained for!

So how do we get the balance we need to succeed? Just like a football team we need to fill our positions to provide the balance. 

The Goalkeeper

The goalkeeper is the guy that stops the opposition ball hitting the back of the net, the one that stops things going against you, the protector from something as ridiculous as the opposition putting the ball into an empty net. 

Ideally your goalkeeper is a preexisting member of the company, someone that has knowledge of how the company works, the intricacies of the system, where people can find the information they need.

They should be at the core of the team supporting and contributing to development, they should ensure that no matter how much brand new shiny work is completed the team don't concede to the intrinsic issues that they wont find through google or their own experiences at other companies, the basic stuff that everyone know except the new guys. You wouldn't play a game of football without a goalkeeper; don't build your software team without one either. 

What to look for: An existing member of staff that understands the environment and ecosystem, someone that can realistically dedicate their attention to getting the team up, running and working, this can be more than one person if needs be.  If there is no existing members then bring in a lead a month before you hire the rest of the team and fill their brain up with as much information as you can.

The Defender

The defender generally protects the goalkeeper, he stops the opposition scoring goals, he's hard working, no nonsense, he gets hold of the ball when he needs to and gets gets rid of it safely and effectively. 

You need a defender in your software team and he carries much of the same characteristics as the guy on the pitch, he gets on with his work, keeps his head down, asks questions when the times right and answers the ones that's asked of him. He's a grafter, a work horse and rarely complains but speaks up when his opinion is valid. His hard work and dedication will keep the ball out of your own net as he'll see you meet your deadlines with little fuss. 

What to look for: Smart developers with a passion for coding but aren't obsessed that they must use and learn the latest frameworks. Developers that can demonstrate a good work ethic and are committed to getting the job done for the team in whatever way the team chooses. They are just happy to be contributing.

The Creative Midfielder

The creative midfielder brings you flare, class and really makes the ball move, the fans love to see him play but don't expect him to be focused on keeping the ball out of the net.

A software creative midfielder will be your driving force when it comes to new technologies, he'll be obsessed with the next big thing and will want to complete the project with 20 new technologies, his passion for whats new will flow through the team and keep your developers engaged and excited, the tech list on their CV's won't look too shabby after working with him either.  

It's important that the creative midfielder focuses on the common goal though, if he isn't pulling his weight when it comes to defensive slog or offering too much creativity and no end product then he may as well not be on the pitch. 

What to look for: Developers who know about the next big thing before it's even come out, developers who have a genuine passion for software and frameworks. Usually into open source stuff.

The Striker

Arguably the most important player in the team, a team is a sum of all the parts but without putting the ball in the back of the net you can never win a game.

The striker is goals focused; they get the project over the line. They are focused on the needs of the business and the timelines they should adhere to. 

They're looking for the creative midfielders to set them up with the best technology in order for them to take it and put it in the back of the net. Like a good striker these developers are often rare.

They need the stability to come from the defense and goal keeper to ensure that they get the project win without conceding along the way.

What to look for: Developers with a keen business sense, good work ethic, they're personable, have good soft skills and can converse with management and business stakeholders, they're leaders. They have a wealth of experience.

In the world of football you get defenders that score and strikers that are good at defending from the front or when there's corners; the same is true for developers they can be versatile; utility men, that will take on any position.

No developer wants to be the guy slugging away without doing some of the fun tasks, or getting excited about the new technology. 

Similarly, you can't have one team member having free rain adding in 50 new technologies, he's got to be a team player, realise that leaves the team exposed and do his part to defend, he needs to realise that sometimes you have to filter down some of the creativity for pragmatism, the striker will be more than happy to tell him this in order to get the project in the back of the net.

In an ideal world your developers will be an equal composition of all the parts and as developers it's what we can aspire to be. 

The Psychology Of Software Development - Part 1. Telephone Interview.

Interview - even the word can strike fear in the hearts of men and women. I'm not sure I've ever met anyone that actually likes interviews, and I most certainly haven't met anyone that likes giving them. I've sat on both sides of the table and experienced the feeling of a successful interview and a few not so successful ones.

A lot what what is being asked of in interviews is quite frankly useless in ascertaining whether the individual being interviewed will actually be able to perform long term in the role, we'll get on to that later..

In my 10+ years experience I've encountered a lot of interview techniques, It's a spectrum, and I've generally found the more highly regarded the company in the tech world the more complex the interview process is. 

The initial phase usually takes the form of a telephone interview which this blog post covers.

Now the phone interview can be tricky but if you follow a few simple rules it should put you in good stead for breezing through.

The phone interview might get technical, it might not, a non-technical call can be just as revealing for the interviewer and there are a few distinct things which they'll be looking for

Can you communicate clearly

Aim to speak clearly, it's worthwhile finding a space you can do this in where it's quiet and you won't be disturbed, book time out in your calendar to have the conversation; a non-technical phone interview is going to look to tick the box that you can communicate clearly and you care enough about the role to give your interviewers time some respect.


It's sometimes difficult finding a space to do this when you're already in a job and understandably we usually prefer some discretion when it comes to your current employer knowing of our intentions to leave; whispering under the stairs isn't going to give the best impression over the phone. I would always try and organise a call later on in the day, if you're work hours are flexible then leave early and organise a call for 5.30 - 6pm. If you're better on a morning then go for that, however, I always thinks it's hard to engage your brain first thing for both you and the person interviewing.

Are you showing some enthusiasm about the role

The easiest way to show enthusiam is to not give one word answers, the interviewer is looking for some insight into what your thought processes are like and what your practical working experience is. The tone of voice you use is pretty important too, it's not a case of being in your face, one thing i always do is try and be personal, speak to your interviewer warmly, like a friend, it will make them want to work with you.  

Can you expand on your CV with some real world examples

I always think it's worthwhile having a print out of your CV in front of you, make some notes on the most recent job(s) that you've had, annotate with things that went wrong in projects, what went right, the stuff that you wouldn't think to put on your CV but are a bit more juicy and show you've got experience in things going wrong and problem solving in those times. Also have to hand times when things went right. Don't get too domain specific, keep it high level, as an interviewer i'm not looking for you to list all the objects in your common libraries to get to the point of the story..

Do you know something about the company

Google them before.

The higher level more abstract stuff is genearlly easy to talk about, you can talk about your past wins and losses because you've lived through them and you can prepare for the questions, what's not so easy to prepare for is very technical and specific questions about frameworks and languages.
Again, it's a spectrum, for the most part over the phone I’ve tended to find that it's more a general discussion about the types of technology you're using and information about current roles.

I've had some really bad phone interviews that get really technical with pop quizzes, one interviewer asked me to name a data collection type, then asked me the last time I used it and what I used it for, when I explained when and what I had last used a generic list for their response was “That's not really the answer I was looking for!”... OK..

Interviewers may ask you in depth technical questions, it's difficult to prepare for this given the vast spectrum of software development, that said, one thing that you should consider at the very least is to prepare based on what you have written on your CV.

If you've put dependency injection then make sure you can explain what dependency injection is.
If you've stated Agile then be able to explain what a user story is, or a story point.
If you've written TDD then be able to explain why TDD is useful and the stages you perform in TDD.

In some cases you may just get what I like to call trivia questions, if you know the answer then great, if you don't then they can make you feel insecure and foolish, it's hard to account for every possible element of every single framework and language you use, especially in todays market, if a company is pop quizzing you in an interview then they are looking for a very specific type of candidate, this may be you, it may not be.

You can mitigate for this by at least taking time to understand common interview questions thing like "what's the difference between abstract and virtual"? In a later post i'll pull together some common questions that are worth reading up on.

Finally, it's important to recognise that the interview is a two way street, you should be critical of how businesses present themselves to you and the questions they ask. Interviewers can get it wrong too, be critial of how they approach their questioning and allow that to be reflective of their business.

I've personally never worked in a company where they've ran up to my desk and thrown .net triva questions at me just to check i'm up to the task; to an interviewer that may signify developer greatness, to me it signifies they're looking for a memory box rather than someone that thinks outside of the box.

We live in a time where software developers are in demand, you're lucky enough to be able to take the time to choose the right role, but make an effort, learn about your trade and be passionate in how you speak about it, if it goes wrong, learn from it, be ready for next time. It may take a few to get it right but you'll get there.

The Psychology Of Software Development - A Blog Series Introduction

Over the coming weeks i'll be posting a series of blogs around my opinions on some of the non technical aspects of the software industry, the soft skills side, what you could loosely call the psychology of software engineering.

I've been lucky to experience a lot of different working environments over the last 10 years and I've witnessed a lot of working styles and more importantly, come across a lot of different personalities and developer types.

The aim of this blog series is to question some of the decisions companies are making in regards to hiring, how they put teams together and to give a view from a developer perspective on some of the business strategy that's forced upon us.

I also want this series to serve as a guide to other developers that are maybe starting out in their career, looking to build teams of their own, or, perhaps, just want to read about another developers view point on the more sticky sides of the industry.

I'll aim to give some tips on how to avoid certain situations, what to look for when hiring developers and moreover how to deal with some of the more tricky situations and souls you may encounter.

The Psychology Of Software Development - Part 1. Telephone Interview.
The Psychology Of Software Development - Part 2. Building Premier League Quality Software Teams

Nuget Package Errors DNX451 & 5.0

We've been early adopters of Asp.Net 5.0 and MVC6 by using the framework for an A/B test that we are performing.

One thing that has been most apparent is the impact of nuget packages in the application and more specifically the nightmare that can unfurl when with nuget packages can't be found and and the project won't build.

The key thing that took me a while to figure out is that using the command line along side the Visual Studio tools is imperative to getting the application to build correctly against the correct version of the framework.

In the early stages of the framework when the Beta releases are being released against a consistent release cycle it's important to know the few key commands to get you through the pain that can occur when you aren't aware of whats going on with your packages.

What we've found is that right clicking on the project and selecting "restore packages" can sometimes work but many times just fails.

In the instances where the application won't build, there are a few steps we can take to get the application to work, this is really important in the case where you might have upgraded your application to the latest beta but the rest of the team you work with haven't.

If you haven't set up the visual studio command line you can find the details on how to do this here;

I always start by navigating my powershell location to the project in question.

The first step I get the guys to do when something won't build is:

dnvm upgrade - this will upgrade the dotnet version manager to include all of the latest versions of the framework.

Once we have all the versions we should choose the version that we wan't to use our project by executing:

dnvm use --version 1.0.0-beta8 (with the version being the version you wish to use against your project).

Performing dnvm list should show the list of current projects and you should see a star next to the project you've set for usage.

Once we have selected the version that we want to use, we need to make sure that the packages in our application are correct and matching the version of the runtime that we are using.

In order for this to work we need to ensure that all of our nuget package locations are in check, the locations I have setup in my global nuget config are as follows:

    <add key="" value="" protocolVersion="3" />
    <add key="" value="" />
    <add key="AspNetVNext" value="" />
    <add key="Roslyn" value="" />
    <add key="DotNet" value="" />

You can find the global nuget file at: C:\Users\<your account>\AppData\Roaming\NuGet.

The final step to run is the restoration of the nuget packages by running the following command in the project directory location:

dnu restore --no-cache

This should restore all of the packages to their correct state with the correct versions of the packages for the currently selected runtime. from here we can navigate back to Visual Studio, rebuild our project and all of our dependency errors should disappear!

StructureMap and 5 VNext

I've created a working example of how to integrate StructureMap with 5. IoC in VNext comes out of the box but if you want to bring your own container you can.

Below you can find a full working example of how to integrate with MVC 6.

EDIT: I removed this repo, as it got stale,  proper support has been created here:

Shouldn't need to roll our own now:

MVC6 and the IHttpContextAccessor

I've been working a lot with 5 recently using the RC of visual studio 2015. There is considerable changes in both the .net framework and of course MVC.

One of the most significant changes is the dependency of 5 on the System.Web DLL. This DLL, that pretty much underpinned all that was web development, has been broken up into independent granular nuget packages that allow you to ship your application with exactly what you need.

Applications that we've used in the past have relied heavily on the HttpContext class allowing us to access the current context by the static property HttpContext.Current.

In 5 large parts of the framework are now Dependency Inject-able. In order to access the current context you can simply inject the IHttpContextAccessor into your class in order to access the current context.

The beauty of this is we can then create our mocked HttpContext using the DefaultHttpContext object that can be found in Microsoft.AspNet.Http.Core.dll

Don't forget all .net code is now open sourced and this particular interface can be found at:

The interface has also been moved to:


As of RC2 some changes have been made to the IHttpContextAccessor and it's availability. The announcement on this change can be found here:

AWS Deploy Failure

In trying to use the AWS Toolkit to deploy our .net application packages to elastic beanstalk we encountered a rather strange error:

[Error]: Caught exception probing for redeployment mode, Object reference not set to an instance of an object.
Failed to parse deployment configuration file: Deployment failed during post-processing of configuration settings.

Unfortunately this error told me very little and searching the web provided no resolve.

After speaking to Amazon it tuns out that the Frankfurt region does not support any version of the AWS toolkit prior to 2.3.4.

Updating the toolkit ultimately fixes the deployment issue.