Agile : The Circuit

Ohm’s law defines the relationship between the voltage, current, and resistance in an electric circuit: i = v/r. The current is directly proportional to the voltage and inversely proportional to the resistance.

Agile from a business perspective is all about zoning in on what it is that is really required to offer the highest business benefit, in the shortest space of time, a.k.a. finding your Minimum Viable Product (MVP).

There can be a lot of ceremony in Agile, I get the impression that this is what takes the front seat in people’s minds, particularly those that would consider themselves “non-technical”.

Agile, to a Developer, should be about far more than just daily Stand-ups and Retrospectives.  Agile is a mindset and an approach, focusing on improvement, reducing your resistance.

It’s vital that any improvement you identify gets fed back into future sprints, like electrons flying round a circuit, this is what keeps the lights on.

Your backlog is your potential, like a battery, keep this topped up with ideas, both business, and technical and you will be able to run indefinitely.

Your voltage (potential difference), is what you can achieve between your two fixed points, start and end of the sprint; with your throughput, current, being everything you can potentially achieve, relative to your impedance.

As responsible Developers, we should be maximising output, and identifying and feeding back on anything that can possibly reduce our resistance.  Sure there will be no surprises here, but:

  • Improving build/deployment processes can help greatly, with DevOps as a discipline justifiably being huge business now;
  • Refactoring our code can make it more malleable and open to change, again another Agile principle, see Software Craftsmanship;
  • Scope changes mid-sprint can be a huge impact to output, this may not be fully understood by business owners, it’s important to feed this back, we would know about it if we waste their time, the opposite should also hold true (communication, and a good rapport is key here!).

Think about what you can do within your team to reduce your resistance and increase your output.  Talk it through with your peers and make a list of improvements you’d like to make, over time it’ll make your bulb glow brighter.

Development Team Membership : Part 2 – Apologies

A lot of people struggle with apologising.  It can be difficult, particularly in the workplace, but apologising even for little things can make a big difference to those around you.  Couple of really obvious examples:

Sorry, I broke the build

Sorry, I’m not going to meet this deadline

Now, it’s not likely you will need to apologise very often; in fact, if you are, it’s probably indicative of a wider issue. In the above examples, maybe you need some coaching on TDD from peers, or maybe you need to be empowered to push back on an imposed deadline.  There will be occasion, however, when things don’t quite go to plan and you just have to hold your hands up and say “Sorry”.

Apologising shows ownership and responsibility for your actions, which for me have always been key qualities with respect to choosing who I want to work with.  Those with “Teflon Shoulders” tend not to last very long.  It also shows a respect for your peers, they will know you dropped the ball, denying it will do you no favours in the long run and a prompt apology can make all the difference in getting people on side to help with a resolution if needs be.

What is an apology?

To me, an apology has very little to do with what it is being apologised for.

What’s done is done, no point crying over spilled milk, and so on.

In fact, in my head, I’ve probably already moved on…

Time Travel
Time Travel

So, what is it?

To me, an apology is:

  • a contract of intent not to make the same mistake again;
  • a display of ownership of your actions;
  • respect.

Not apologising, is the opposite:

  • a contract of intent to make the same mistake again;
  • shirking ownership of your actions;
  • disrespectful.


An insincere apology is worse than no apology, if you don’t mean it, don’t say it.

Closing Thoughts

It’s rarely too late to apologise, (especially if you still have a job!).  Apologising can help you get something off your chest and also have a profound impact on those around you and the way they act towards you.

Is there anything you’ve done and shrugged off into the Ether?

Next time you do something a little bit questionable, at work or outside (we all do, don’t deny it), apologise and see where it gets you.


Development Team Membership : Part 1 – Moaning

I recently made the transition from Permanent Employment to the world of IT Contracting.  Along with this change, came a different role for me with my new client; a much more hands on position writing a lot more code which is exactly where I wanted to be!

I previously wrote a series of Blog Posts providing tips for Development Team Leadership, this has dried up of late due to my change in circumstance, however I would like to now start sharing some tips for Development Team Membership, having worked on both sides of the fence.

Don’t moan without a resolution

Moaning is great.  Everyone loves a good moan, myself included.  Moaning can be helpful and healthy, in fact indirectly it’s part of the agile feedback loop, what went well, what didn’t.  Accompanying this, should always be next steps; how to negate what grievances you may have.

There’s definitely a right time and a place for moaning sharing your observations in the context of your team, you’ll be best placed to know when this is, but it may typically be a team retrospective, a workshop on where your team is heading or a one on one, planned or impromptu session with your mentor/lead.

As a software professional, keep it impersonal.  You won’t want to come across as a bully, picking out specific people’s faults or shortcomings is never helpful.  Code reviews should be used to increase code quality, but be cognisant of their feelings and how you may be perceived.

Mr Muscle, loves the jobs you hate

You can’t always have the glamorous roles in the team, sometimes you just need to roll up your sleeves and get stuck in.  As a good team player you should have no qualms in doing the grunt work.  Grunt work leads to insight, and insight can lead to improvement in process.  Developers are lazy, and that’s no bad thing.  Do something once, do something twice and automate.

Don't skip Leg Day
Don’t skip Leg Day

Don’t shy away from hard work.

Improvements Log

You’re the one with the low level knowledge of your application(s), any potential improvements that don’t fit within the confines of the piece you’re working on should be logged, to be addressed at an appropriate time.

This will serve to broaden the teams understanding of how they should all be writing software, e.g. coding standards/patterns, and, in the same way that code reviews serve to manage quality going in to an application.  Improvements serve to keep the application up to date.  As soon as it’s committed, code becomes legacy, it’s a valuable resource and an opportunity to improve, it, and yourself as time passes.

An improvements log can serve as a satisfying alternative to a good rant.  Log it and move on, your lead should be monitoring the situation and pushing things forward.

Holiday Reading : Cyprus

I spent the past couple of weeks in sunny (excruciatingly hot) Paphos, Cyprus.  In a similar vein to last year’s Holiday Reading : Lanzarote, I took a lot of reading material with me…

With the exception of Sharp Ends they are all quite old books that I had never got round to reading.


Sharp Ends – Having read all of Joe Abercrombie’s other books this latest collection of short stories was recently released, thankfully in time for my holiday.  It didn’t pull me in quite so far as the other books, but such is the nature of the short story beast.  It’s always great fun reading about “The Bloody Nine” and the new characters introduced left me wanting more.  Hopefully more is in the pipeline.

The Da Vinci Code – I watched the Da Vinci Code film many years back.  Aside from vaguely remembering there was a blonde monk who enjoyed whipping himself, all other details had been lost.  I read Angels and Demons recently and decided to continue with The Da Vinci Code.  It’s fascinating how Dan Brown mixes history with story.

The Moon of Gomrath – This is another old book from the 60s, I read the Owl Service last year, and subsequently Elidor.  Fast paced high fantasy, not a long read and won’t be for everyone.  If you like Wizards, Cat Armies, Dwarves, Elves, Possession and Witches you’ll like this one.

Adrian Mole – Sparked by a recent conversation in the pub with a couple of friends I decided to revisit Adrian Mole’s Diary.  The stories are hilarious and level of detail make it so easy to relate to.

The Restaurant at the End of the Universe (Hitchhiker’s Guide Book 2) –  Another Comedy classic, Hitchhiker’s guide will no doubt be familiar with a majority of the audience likely to be reading this blog given the subject matter.  The humour is incredibly sharp and had me chuckling to myself (and groaning) throughout.

Paphos Shore
Paphos Shore




Web API Tutorials Part 5 : Azure Deployment from Visual Studio

Microsoft have made it extremely easy, almost trivial to deploy your web applications to the Azure cloud from Visual Studio.  Cloud capability is incredibly powerful for scalability, particularly in enterprise level applications and affords Developers with the option to make their infrastructure as Agile as their Software.


By the end of this tutorial, we’ll have deployed our Web Application directly into a Web Site in Azure using their Platform as a Service offering (PaaS), meaning we don’t need to worry about a Virtual Machine, updates, and a myriad of other concerns. Continue reading Web API Tutorials Part 5 : Azure Deployment from Visual Studio

Web API Tutorials Part 4 : Controller Attribute Based Routing

Web API offers some powerful routing behaviour.  Let’s look at how we can use this in our app to avoid needing a new Controller for every Translation we wish to offer (again, ignore the fact our sample is likely only ever to require two way!).

We currently have a single AlphabetToMorseController with our old ITranslator implementation.  In the previous tutorial we abstracted our service into an extensible dictionary, this should allow us to take our Translator Key as a routing parameter and our string to translate as a parameter in the URI on our API.


By the end of the post we’ll have refactored the existing AlphabetToMorseController to a generic TranslatorController, with our ITranslatorService being injected.  The Key will be provided through a Web API Route, and the Get Requested to the Controller will return a collection of available Translators. Continue reading Web API Tutorials Part 4 : Controller Attribute Based Routing


I set myself a personal goal recently…

publish a Library on NuGet.  So that’s exactly what I’ve done.

SqlBulkCopyCat is a configurable wrapper around SqlBulkCopy in .NET for SQL Server, born out of a personal frustration at work of being pushed towards using SQL Server Integration Services (SSIS) for copying large amounts of data between databases with no real alternative for anything robust without the baggage of taking on SSIS dependencies and the associated bloat in the Development Environment.

Continue reading SqlBulkCopyCat

Review : Dark Days by D. Randall Blythe

As a drummer, Chris Adler of Lamb of God has always been an idol of mine (his signature sticks are my go to), and I’ve been a huge Lamb of God Fan for a number of years now.  The story of their front man, Randy Blythe getting arrested on Manslaughter charges on landing in Prague Airport, Czech Republic two years after the alleged incident was truly shocking.  His book, Dark Days, recounts the ordeal and offers an insight into his incredibly strong outlook on life and how he made it through the other side.

Continue reading Review : Dark Days by D. Randall Blythe

Web API Tutorials Part 3 : Translation Abstraction

There’s a famous quote in the world of Software Development:

“We can solve any problem by introducing an extra level of indirection.”

In my experience, this is almost certainly correct, this post will see us adding in an additional layer of Abstraction to allow us to simplify our Controller(s) and manage our Dependencies in a more straightforward manner.


Last post saw us implement our Translation PCL into our Web API using Dependency Injection.  The problem is that our ITranslator Interface only handles a single Translator Implementation, such that when we inject from our Container we can’t currently translate more than one direction.  We’ll look into the why’s shortly, but by the end of the post we will have created :

  • ITranslatorService Interface;
  • TranslatorService Implementation and Unit Tests.

Continue reading Web API Tutorials Part 3 : Translation Abstraction

Web API Tutorials Part 2 : Translation PCL with Dependency Injection

Portable Class Libraries afford great benefit when it comes to sharing code across platforms/usages.  We can share a single library across our UWP App where it’ll run locally and on our Web API where it’ll execute behind our endpoint.  Dependency Injection has been made very accessible with the latest ASP.NET MVC Web API.


The current MorseCoder.PCL targets only Windows 8.1 as it’s point of API Reference.  We’ll need to change that to extend it to the wider .NET Framework (we’re not doing anything prohibitive, so this isn’t a problem).  By the end of the post we’ll have updated our PCL to target what we require, and integrated it into the Web API Project using Dependency Injection to pull in an instance of our Translator from the IServiceCollection container.

Continue reading Web API Tutorials Part 2 : Translation PCL with Dependency Injection