The System Rules

I have worked in numerous companies and roles over the past 15+ years.  Culture and behaviour are a symptom of the system. 

I will level with you; I do not like job roles or titles they are symptom of the system.  More specifically I now consider myself a problem solver – even though this is a role, whether that be Front End, Back End, DevOps, QA, BA, PM, coach, leader, mentor, etc.  I will do any role that needs fulfilling to ship valuable working software to the customer.  I have got areas of specialism, areas I am ok at and areas where I need to read and learn.  However, on a personal note I love learning new technology and techniques.

Back to the system, if you create a system with job roles – more specifically the trend that I see now is the split between Front End vs. Back End & the new Full Stack role and the more traditional QA engineer or DevOps engineer.  That is the system, people’s behaviours will start to align with the roles.  For example – ask a DevOps engineer to do some React or Angular in this system and the likely hood is that you will get push back.  That is not my role, I’m employed as a DevOps engineer and all I do is Terraform and AWS! 

Delivering working software does not occur in a silo of work, do Front End then Back End – at any point you could be a stakeholder, PM, PO, BA, Front End, Back End, QA, DevOps, Release Engineer, etc. 

My experience of highly successful teams – read delivering valuable software to customers, with short lead times. Is that most team members will be needed to fulfill any role while delivering software. 

Having push back just creates queues and expands lead times.  Oh, the Front End dev’s just finished the UI, but the Back End component isn’t ready.  Software sits there waiting in a queue before the Back End work is done.  Queues kill flow.

Continuous Delivery

The ability to deliver code all the time, sounds magically. I propose most companies aren’t that far from enabling this within their development teams and even their legacy code bases. One of the most common arguments against is that we don’t have enough automated tests to continuously deliver.

I’d argue that the 4 things you need to enable continuous delivery are:

  • continuous integration
  • a minimum of 2 automated tests
  • monitoring
  • blue green deployment setup

The most important is the ability to monitor the changes going to live. A good start is something like NewRelic which is easy to install on production boxes and gives a good feeling for whether your application is healthy or not.

When talking about automated tests, my preference is to test the most important part of your journey. For an ecommerce site this would be placing an order as a guest. Then the second test might be placing an order as a signed in user. My maximum for these kind of tests (if you are thinking Selenium) is around 5 at the most. Once you have these tests in your build pipeline you are a step closer to continuously deployment.

Finally having a blue, green setup for deployment is essential, so if the monitoring is showing you a change has broken something you can simply revert quickly. Then fix and re-deploy as quickly as possible.

There is obviously a caveat to this, try to start deploying smaller increments to live – ideally one changeset. Then if something goes wrong you know what has broken it.

I don’t propose no Test Driven Development, or no testing.

I’m just proposing that it’s not as hard as you think it is to get to a point where you can continuously deliver software. I consider continuous delivery to be an ability.

3 Weeks of Kanban

So we’ve had the kanban (note the small k!) board for nearly 3 weeks now. It’s been quite a learning curve. Especially since a few of us know the theory and some are really new to it.

The first thing to know is that the daily stand up is a new idea, so quite a few people are alien to what the purpose of the meeting is. This makes it seem quite an arduous task to stand in front of the board for 30 minutes initially (times have come down in recent weeks).

This is primarily due to a lack of shared knowledgeunderstanding of the purpose of the daily stand-up. As I will now highlight!!!

Compared to a SCRUM meeting the Kanban daily meeting is significantly different. My understanding of SCRUM meetings are that they take the following format, each member of the team say’s:

  1. What they did yesterday.
  2. What they plan to do today.
  3. What issues you have.

Having read about these meetings, my general understanding is that they do not scale – i.e. they start to take longer than the 15 minutes allotted when you have more than 10 team members (note: everyone is involved!).

My understanding of the format of a Kanban meeting is as follows:

  1. Highlight anything that is “blocking” a work item – we call this an “Issue”.
  2. Pull the next work items in from “Done” columns.

I’ve read that mature adoptees of Kanban will actually perform a retrospective during the meeting. I.e. why is this issue preventing this item from moving? How do we prevent this from happening again?

So you can see that I have a specific understanding of daily stand-ups! How are we going to share this knowledge?

Well today I’ve been trying to write the ideas above in to an “explicit policy”. So now we have a “Purpose of Daily Stand-Up” – which ironically has the information highlighted above. This is a single power point slide – the key here is brevity (which I’m not very good at most of the time!).
We also needed a definition of an “Issue” so that people are aware of what we are trying to highlight during the meeting.

“Solving Issues” also has a definition and ideas of how to solve issues. The most important thing is that anybody can solve the issue. Another important thing is that the issue is taken away from the daily stand-up – otherwise it turns in to a conversation between only a few people; then no progress is made during the stand-up people not involved in the conversation get bored.
All of these lead in to a Retrospective – i.e. “How can we improve flow?”, “How can improve different areas of our process?” These are placed on another slide. So now we have four slides which hopefully outline “explicit policies” or definitions – hopefully these will help over the coming weeks.

Other things that we probably need to consider:

  • Size items – could we use T-Shirt sizes?
  • Mark on items when they move – i.e. transition to “Done”, transition to “In Progress”.
  • Mark on items each day they are in a certain area on the board.

So to summarise some important lessons:

  1. We are always learning.
  2. We have plenty of good ideas from all the team for the board.
  3. The board will change.
  4. We probably have too much Work In Progress.
  5. Meetings need a purpose or goal.
  6. Meetings need an agenda.

Test Driven Development – Personal Retrospective

Over the last year, members of our team have realised that we need to change the way in which we work, this is both as a team and as individuals. The first stage of this is in the realisation that we are actually doing something wrong in the first place. This is a personal experience of mine with regards to Test Driven Development (TDD).

A key realisation was that we need to ensure that quality is higher; quality is always a word which makes me think: What is quality? How do you define quality? I often think that quality is one of the most subjective words in software development. I’ve come to realise that quality isn’t just about how good the code is. It’s about meeting the customer expectations as quickly as possible – that’s the purpose of our job (the Agile Manifesto highlights this).

One of the key things to quality is that getting through system test shouldn’t be a chore. It should be a pleasant experience and the amount of back and forth between System Test and development is a good indicator of poor quality. (Note: this isn’t the only measure of quality; this article isn’t about code quality). This should be reduced to the minimum. This is twofold:

  1. It can cause friction between developers and testers.
  2. More importantly it ends up costing you a lot – of trust, and more importantly money.

Unit testing has been around since the computer was born – well programming was born. I wonder whether Ada Lovelace had Unit Tests. I recall my time at University and that my key lecturer – Tony always wanted you to have test harnesses before he’d accept your code for assignments. This meant you had a suite of tests which ensured you substring written in assembler would work. You’d pass in certain strings and then see whether the expected came out – failingl the test if it didn’t work.

I often wonder where I lost that skill or why I forgot to do it. After I graduated it all became about writing code and getting it in to production as soon as possible. It didn’t matter about the tests; it just mattered about getting the code out as soon as possible. How mistaken I have been. I must have cost companies a fortune; I’ve been for interviews where they asked, “How do you test code?” – press F5 and play around with edge cases was generally my answer. You could see their faces – “What about NUnit?”

Big admission I know. For me over the past couple of years I’ve come to realise that software development is all about learning, the faster that you can learn the more adaptable and more progressive you become as a developer.

It’s taken me about 6 months to get used to Test Driven Development, and get it (nearly) completely embedded in to my development practise. I now feel that I have a better understanding of how to write tests, and write better quality code as a consequence. This hasn’t been easy – it’s been hard work, changing the habit of my entire (semi) professional programming career. Write the tests first, and then write the code to make those tests pass.

It is amazing that it now “feels wrong” to be writing code which doesn’t have a test. How weird I wouldn’t have cared a couple of years back. It’s definitely been a learning experience and something that I am now keen to share with other professionals as well.

Once you become passionate about a technique it can quickly rub off on to other people.

Four years on…

It’s been nearly four years since I posted on this blog. Ain’t that amazing!

I’ve learnt so much over the last four years that it would take me such a long blog post to update anyone who might be reading…

However, to summarise:

  • I am still a .Net developer.
  • Agile is amazingly interesting.
  • Kanban & Lean are probably the next step in Agile – although they may not be exclusive.
  • C# is still a cool language.
  • I’ve learnt that learning is key to being a developer. Always strive to improve yourself – never stop.
  • I still climb – English – E5 & French – 7c!
  • I have an amazing partner – although she is from the other side of the World!
  • I have a new niece who is beautiful 🙂
  • I continue to expand my network of climbing friends :).
  • I’ve started using twitter –

That’s about it!

Dzien’ dobry Polish people

Well this is strange, I’ve just been looking at the stats for this very website, and I kinda guessed that quite a few people would be from the UK, so amazingly 76% of the share is UK visitors… However, I kinda thought that US might be the second, but hold on, nope Poland by 6% – 13% of the visitors share… This is so geeky I know but waiting for CRM 3.0 to configure on the Server and thought I would have a look at the stats… So anyhow, thats it, just wondering thats all!!!

Oh yes CRM configuration am going to put this here as well if you are upgrading from 1.2 to 3.0 and get the following error:
“The foreign key constraints in the CRM database are not consistent with CRM 1.2 foreign key constraints.”

Do the following:
1, Look at the CRMV3setup.log found in “C:Documents and SettingsApplication DataMicrosoftMSCRMLogs”
2, Example of the error logging is:
23:14:25| Info| The following foreign key constraint(s) are not consistent
with Microsoft CRM 1.2 foreign key constraints:
23:14:25| Error| remark: deleted foreign key
23:14:25| Error| tablename: leadaddressbase
23:14:25| Error| columnname: parentid
23:14:25| Error| referencedtablename: leadbase
23:14:25| Error| referencedcolumnname: leadid
23:14:25| Error| foreignkeyname: lead_addresses
3, Now I had a different error, so I reinstalled CRM 1.2 on a test machine and then checked the databases like this. Through the GUI, it is usually in the tablename: that the problem is.
4, Alternatively you can run/modify this (I didn’t have much joy doing this such is why I suggest reinstalling 1.2 on a different machine.
4, a, First drop the constraint on the table.
4, b, Then:

ALTER TABLE [dbo].[LeadAddressBase] ADD

ALTER TABLE [dbo].[LeadAddressBase] ADD
) REFERENCES [dbo].[LeadBase] (

This is rather annoying

Well I wanted to post some pictures of climbing on Saturday, and potentially me with the medal on Sunday but alas I can’t upload photos to my blog currently. This is rather annoying, and well this is with Google, so sort it please Google…

I’ll just surmise, we (Will and me/I (for all you grammar freaks)) had a good day on Saturday at Robin Proctor Scar (formerly known as Norber Scar). We did 6 routes with the sun actually appearing for selected moments of the day, but in the end the wind prevailed and we were too cold to carry on climbing… Alas it was a nice way to carry on introducing myself back to the World of real rock!!!

Then on Sunday we went out for a nice orienteer around White Coppice, the competition was laid down, although it ended up not being very competitive. I still beat you Johnboy, Will and Vicky. Someone moved the first marker so I spent 10 mins looking for it, decided it disappeared and carried on… Yes I did run some of it/most of it, and yes did go over on my ankle because of it, but still ended up winning.

Thanx to Pete and Jenny for organising it, was good fun to have a run about after some flags… I will post some pictures soon, or decide whether to put them on another site and link this to there…