Liquidity matrix – what is it and how might it help your team?

Over the years I’ve seen a number of places of work which suffer from the following, a team member leaves or is on holiday and he or she is the go to developer, the developer that’s the only person who really knows that topic or area and as a result you have to wait for them to return, lets face it I’m pretty sure this has happened to a huge percentage of us, so here is an idea to help with this:-

So for example say we take the following as an example:-


From the above we can figure out that Andy doesn’t know anything about the internal and external websites, perhaps he can be brought up to speed, also Andy is the only person who knows anything about the Deployment and the PowerShell scripts, that means he’s the bottleneck or however you want to put it, other developers should be brought up to speed so that he is not the only person with knowledge in that area, if he went on holiday or left then you have a glaring problem.

You can do this same will skills and this is much more common I have found, and yeah not everyone is keen to admit to not knowing much about a certain area but just reassure them that this is not what this matrix is for.

Maybe some of you will find this useful, hopefully it doesn’t show that your team rely on some people, and its good to share knowledge within your teams.

Lightning Talk – Top 10 Best Practices for Developers

Today at work, Friday 8th January, I gave a 5 minute lightning talk at work and I chose to talk about my list of top 10 best practices for developers, being 5 minutes I hadn’t much time but here is what I talked about with a little more meat on the bone in this blog post.

Keep your kills up to date

  • Use video websites like Pluralsight and the like to keep your skills relevant and up to date so you’re not left behind.
  • Read books
  • Have a blog
  • Use twitter to keep up to date when possible, it’s a fast paced world and its difficult to keep up to date so try to make time

Share your knowledge

  • If you hear about or read something of interest to colleagues pass it on
  • Share the new technologies you’ve looked at or some code you came across which is well written.
  • Give demo’s to your team mates and show them why this might be something worth learning etc.

Have good personal discipline

  • Check your code in regularly
  • Keep your check-ins small, don’t wait days before committing and don’t have one big check-in with hundreds of file changes if you can help it.
  • Keep an eye on your build server, try not to have broken builds for days, when you check-in check your code builds on the build server, don’t be lazy.
  • Tidy up as you go, don’t leave files, folders, backups etc. lying around.

Take an interest

  • Take part in code reviews, add your thoughts and comments.
  • Take part in team meetings, add your voice, don’t be silent.
  • Know your codebase, well as much of it as you can.
  • Know how everything works from writing code, building it, running the tests on the build server and also how does it get deployed, don’t leave it for others to do.

Test Everything

  • Write unit tests.
  • Write Integration tests.
  • Write front end tests.
  • Write tests for your build scripts.

Automate everything where possible

  • Automate Builds.
  • Automate Tests.
  • Automate Deployments.
  • We are engineers so automate, less manual steps the better.

  • Read other team members code.
  • Read code from Github, BitBucket etc.
  • Learn from other developers, there are plenty of great examples out there.

Document your processes

  • Document your build process.
  • Document your servers, accounts, permissions etc.
  • Think of the next developer, maybe a new employee how would they benefit from your documentation.
  • Limit technical debt – keep on top of your technical debt each sprint for example.

Leave the code in a better place than when you found it

  • Clean up your codebase, remove dead code, remove unused namespaces etc.
  • Remove or fix Skipped Tests.
  • Tools like ReSharper can help you clean up code in seconds.


  • Feedback good or bad is important, from colleagues, your boss, your end users/customers.
  • Get Feedback on your software from people who use it day in day out.
  • Get Feedback from your build server, how long are the builds taking, how long do tests take to run.
  • Feedback is golden, and the beat way to improve.

Give Back

  • Do a lightning talk at work.
  • Do a presentation or a demo at work.
  • Giving back can be very rewarding.
  • Encourage people, don’t criticise or condemn.

It was fun doing it and I look forward to doing more talks soon.

Continuous Deployments for SQL Server – Part 3

In part 2, I covered how to compare the schemas of two databases, in part 3 I’ll to cover how to compare the data held within these two databases, for that I am going to use SQL Data Compare.

Again we will use the same two databases, imagine your comparing UAT to Production and wish to compare the data within these two databases:-



(If the links are too small click on the image and then when the new window appears click on Original size at 1896 × 316)

The above image shows us that the t_depot database table has 4 rows which are in the Stock_DB_Deisgn table which aren’t within the STOCK_DB_DESIGN_ORIGINAL database. Again same as with SQL Compare, if we now click on Synchronization wizard we will see the following screen:-


And again as with SQL Compare, we get 2 options:-

  • Create a deployment script – use this option if you want to script the changes and review before running in the changes.
  • Synchronize Using SQL Data Compare – use this option if you want the tool to make the changes for you, you also get the option after its ran to automatically compare the 2 database data after the changes, to verify.

And that is it, easy, simple and straightforward, no manual steps involving creating scripts, no real chance for it to go wrong, plus once again you can source control the script if you really wanted to or share it with colleagues.

In part 4 I’ll cover how to deploy changes to your database whether its schema changes, data changes or both.

Continuous Deployments for SQL Server – Part 2

If you’re using SQL server at work and manually deploying changes to your database using manually crafted scripts then its time to stop, there is a better way to do this by automating it, remove the chance of human error, this will also ensure that before you deploy to production that your changes will work, guaranteed.

In this blog post, I’ll discuss comparing two SQL Server databases which you can use SQL compare to funnily enough compare them and see the differences between the two, very quickly and reliably, imagine you wanted to compare your local Development database with say your Staging database for example, or compare UAT to Production.

In this blog post I’ll go over the steps I went through and how to use Sql Compare to work out what’s changed between the two databases, schema wise, then in the second part I will show you how to use SQL Data Compare. to compare the data within both databases and in part 3 I will either create a script to update the database or run an exe which the tools will create for us to make both databases the exact same, both in schema and in data, so let’s get started.

I’ve made dome schema changes to STOCK_DB_DESIGN and I wish to see whats changed, so lets see how to compare the 2 databases using SQL Compare (I’m using version 11).

In the screen shot above I’ve chosen my databases to compare and the tool will now run and show me what the schema differences between the two. the screen shot below shows the results after the tool has been ran against both databases.


On the left pane we see the changed database, on the right the database without these changes, I clicked on the first row to show the changes in the t_depot table and in the split at the bottom it shows the differences per object – very quick and easy to see what’s changed.

Update time
In order to update the older database with the new changes, we simply click on Deployment Wizard at the top and we get the following screen with options:-


Here we get 2 options:-

  • Create a deployment script – use this option if you want to script the changes and review before running in the changes.
  • Deploy Using SQL Compare – use this option if you want the tool to make the changes for you, you also get the option after its ran to automatically compare the 2 database after the changes to verify.

And that is it, easy, simple and straightforward, no manual steps involving creating scripts, no real chance for it to go wrong, plus you can source control the script if you really wanted to or share it with colleagues.

In part 3 I’ll cover comparing the 2 databases when it comes to data, for this we will use SQL Data Compare.

Continuous Deployments for SQL Server – Part 1

Okay so your using a SQL Server database at work but you haven’t yet put the database into Source Control, here are some reasons as to why you want to do this:-

Source control your database
Trust me your going to want to do this if you haven’t already, it’s a good practice, it may save your skin some day, yes you can take backups which again is a good practice, here is an excellent article on why you want to do this:- Why put your database into source control?.

Okay now that we wish to put our database into source control – we still use Subversion at work so I downloaded Subversion and installed it locally as well as TortoiseSVN.
I have 2 databases called STOCK_DB_DESIGN and STOCK_DB_DESIGN_ORIGINAL within SQL Sever, the former had a few schema changes, imagine this is Development(STOCK_DB_DESIGN) and Staging(STOCK_DB_DESIGN_ORIGINAL).

I created a local repository within Subversion and downloaded RedGate’s Database Lifecycle Management Products.

This tool comes with SQL Compare and SQL Data compare as well as a host of other awesome SQL Server tools which you can find out about at the above link.

For this post I’ll be using Redgate’s SQL Source Control which adds a tab to SQL Server Management Studio and looks something like this:-


So lets go ahead and add a database to our source control using this tool, Select the option above, and then Next


I selected Subversion because at work we still use it, but you can use Git also and others, click Next


I then give it a repository URL, I already created a repository within Subversion for my database and added the URL like above, click Next and that’s it, our database is now linked to source control. Now to get the database scripts into Subversion we need to right click on the Database in question within SQL Server Management studio like so and select Commit Changes to source control:-


This will then add all of the database objects to SQL Source Control, once that’ completed, go into windows explorer and I use TortoiseSVN I can right click within my local SVN repository folder and then select Checkout or get latest version and this will result in the following folders being populated:-


And when I go into say the tables folder I’ll see the following:-


And that’s all there is to source controlling your SQL Server database. If I make change to an object say a table I’ll see whats changed locally in SQL Management Studio and I’ll know I still need to commit the change as seen below:-


In Part 2 I’ll show you how to compare schemas on both databases to work out what changes are required, and how to script them using the tool.

My todo list for work in 2016

Its 2016 and I like to make a list of things I wanna look into and put into place at work so here is a list of things I am aiming to do which also includes at my job in 2016:-

  • A blog post each week, last year I only managed 11 blog posts and that’s poor, so more blog posts will come in 2016.
  • Lightning Talks, we have started doing these at work and this year I plan to do a few of them if given the chance, I’m doing one on the 6th of January on as Developers Top 10 Best Practices which I will share about once I have done my talk.
  • Test 3rd party end points, have a dashboard page which tells us what is up and what is down, going to try to use the Chrome add-on called Postman and use collections within Postman to do this.
  • Database Deployments, currently we manually script everything and then get the dba to run the scripts in manually, we need to script the database and put it into Source control each release as a starting point, I’m looking forward to this as it well help aid with our deployments and speed them up. Hoping to get the RedGate Sql Toolbelt into the company so we can use this to help us achieve this.
  • Red/Green deployments, we currently deploy at weekends and this can and should change so that we aren’t spending time at weekends doing releases which take quite a lot of time, we can automate them more and this year I plan to fix that.
  • More Testing, we are closing in on unit testing our PowerShell scripts, this will be another nice addition to the number of different areas which we are currently testing which is great.
  • Code Reviews, need to figure out a way that keeps everyone from being bored, brings benefit to the team and keeps us developers on our toes going forward.
  • Continuous Improvement, test more, more in-depth code reviews, automate more, release finished work, tackle the back log each sprint.

That’s it for now, I will add to this lost throughout the year as we go, i will keep an eye on this post and how we get on and blog about each one individually, hopefully I’ll get the chance to work on some if not all of these this year.

Feel free to follow me on twitter at @gsuttie

Interview Questions for Developers

The last few weeks I’ve heard some interesting interview questions for candidates and without going into too much detail asking a developer questions like, where do you see yourself in 5 years? just doesn’t cut it for me, so here is a list of interview questions I would ask a developer looking to join a company I work at.

  • Do you have a StackOverflow profile, a Github or Bitbucket repo where I can take a look at some of your contributions or work?
  • Are you a member of any User Groups or do you attend conferences etc?
  • How do you keep up to date with the latest technologies and keep your skills up to date?
  • Do you know more than one programming language and if so which ones and what ones do you like and why?
  • If you’re interviewing and get to the next stage you will be asked to write code on a laptop and write unit tests, are you comfortable doing that?
  • What are your thoughts around TDD?
  • Are you happy to look at some code and review it and give us your thoughts around it?
  • Do you have any knowledge of PowerShell?
  • Tell me your thoughts around code reviews, are they important, if so why?
  • Tell me your thoughts around code coverage, what percentage is reasonable and is it worth while?
  • What is your favourite technology and why?
  • If a member of your team is lazy and not putting in enough effort what would you do about it?
  • Have you ever worked for a difficult boss and if so how did you handle it?
  • Are you ok with doing support on legacy applications and fixing production issue on the legacy code base?
  • What are some best practices you follow, and why do you follow them?

Ok short and sweet and off the top of my head – I’ll add to them over time.