Consistency Coupling

Consistency Coupling

This about the desire to keep things consistent.

When a development team makes a change to a component that is part of a large system they can be proud of their implementation. It can becomes the “way things are done”. The rest of the code base is shunned because it doesn’t follow the new standard. Now there is a desire to go through the rest of the system the improve it in the same way.

Stop, wait!

  • How long is this going to take?
  • When we the team get back to delivering business features?
  • Are these changes really needed?

These are the questions hiding in the background. These are the questions some delivery team will brush under the carpet.

I can totally buy the argument that if you change the look and feel of your application in one place there are good reasons to ensure consistency across the whole application. Your users may become confused by inconsistent interface.s They may stop using your software as a result.

What I don’t buy is the assumption that  consistency should stop you releasing a new feature. Perhaps you are trying something out that looks brilliant to the delivery team but when rolled out might causes your users to run a mile. In these circumstances the impact of the new feature should be measured. Only then will you know the true impact.

So when inconsistencies can impact you value stream I can be to swayed. But when I here technical arguments that say that we have to stop delivering new features for a while because this code change that was made to component A now need to be implemented across components B, C, D and E.

Often A, B, C, D, E are independent logical services. So the argument is saying because we changed A, we also need to change B, C, D & E. This same to contradict the assertion that services should be independent. Are we really arguing that the cost of changing one service increases exponentially as we build new service?  That makes no sense. We have a service based architecture to decrease costs not increase them.

Services communicate through interfaces to reduce implementation coupling

Services communicate asynchronously to reduce temporal coupling

Enforcing consistency across a code base causes build time coupling

I total empathise with the delivery teams OCD when they open up the code and see that services A and B have a terrible implementation when compared to services C’s elegant version. But in constantly evolving code base, the code will never be perfect at any point to time. You can never stop the clock and make everything perfect and even if you could, the moment time started running again the code would diverge and perfection would dissolve. In this way a code base demonstrates entropy. Over time and without a positive influence a code base will tend to disorder.

Dealing with this as technical debt. When improvements are spotted log them and even spend an hour or so improving  them yourself. But be cautious. If you have improved some code in a service that is not part of the feature set your team is working on that code may not be released in the short term. It may never get released.  It has no value if it is not released, so it is important to ensure that you don’t get distracted from the work you “should” be doing.

But lets follow this dark path a little bit more. Lets say you have invested the time and you want to realise the value of the work. Now you have to release this service alongside the rest of the team’s work. Ideally this would have little impact but experience tells me

  1. The release process will be very so slightly more complex
  2. There are more things to go wrong
  3. You get more questions about why “Service B” needs to be released when this increment is about changes service A

More effort, more time and more cost. You have coupled your change to the bulk of the team work purely for consistencies sake. Expand this problem to many services and you’re back to your monolith and you no longer can deliver cheaply, frequently and reliably. All this for consistencies sake.

If your application is such that you should drive for consistency at all cost –  you need to accept that impact and deal with the consequences – namely changes are likely to be slow. This should be a very rare case. If your priority is getting new features to your customer then you may have to deal with the fact that you application’s code may not be consistency.


Is Scrum anti Agile?

Is Scrum anti Agile?

When an organisation is moving from a top down process such as waterfall to an Agile methodology like Scrum, for the people involved it can feel like everything is coming off the rails. All the comfortable and reliable “process” is gone and now you really have to think. Change can be difficult and this type of change is no different.

When moving in this direction, a process or a framework is a safety net or a comfort blanket. If you are not careful people can miss the point of the Agile transformation and instead focus on the framework, methodology and tooling. Work management tools such as JIRA, which are a bit of a swiss army knife, can, if you are not careful, become another facet of the process safety net. Before long your work management tool is configured with so much “process” people have stopped thinking and any Agility that was blossoming in that organisation is slowly evaporating.

But let’s look at it from the other angle. Some small organisations have little to no process. From an outsider’s perspective, it looks like chaos but the reality is that these organisations have started from nothing and now have paying customers, so they must be doing something right.

These organisations might be looking to frameworks like Scrum to provide some stability and some predictability. They want to build on a successful foundation and grow without losing what made them special in the first place. So, you might look at implementing Scrum and related tooling simply to manage stories in a backlog. You might encourage using sprints to create a delivery cadence.

And then the backlash starts. In the same way waterfall practitioners think you are trying to take away their comfort blanket, so do the developers in the start-up that needs to mature. Whichever way you look at Scrum it has some rules. Okay, they may be called a framework but they are still rules. These rules drive home the point that to be stable and predictable you cannot have a free for all. The transforming organisation may start to realise that their current ways of working are not special and instead they need to conform with what the majority of the industry is doing.

In this situation, you must realise that processes or frameworks, even lightweight ones like Scrum, can be seen as a burden when transforming chaos into stability. While it might seem like common sense to you, the people undergoing the transformation may believe that agility is being lost, along with the innovation that got the organisation to that point in the first place.


Never ending stories – Agile Anti Patterns

Never ending stories – Agile Anti Patterns

The Never-Ending Story was a 1984 fantasy film about a boy who reads a magical book that tells a story of a young warrior whose task is to stop a dark storm called the Nothing from engulfing a fantasy world.  Apparently it was quite good but all I can remember about it is the large white flying dog like creature.

The Never-Ending stories I am more familiar with are those in Agile projects that start out as something that is assumed to be quite straight forwards but then generates much more work than was expected and before you know it, not only are you carrying it forwards into the next sprint but it starts reoccurring in multiple sprints. So, what are the characteristics of a never-ending story.

A story really represents a feature and as such becomes a bucket for all areas of functionality related to that feature

Agile is about reducing feedback loops in order to build confidence that you are always working on the most important thing at any given moment. Often never-ending stories internalise that feedback loop. Maybe the story represents a new area of a solution. You don’t what to do too much up front design or suffer from analysis paralysis so you have a story that enables you to try a few things out. This is reviewed with the Product Owner and the rest of the team which generates new ideas which is new work.

There is nothing wrong with this description so far, however a never-ending story emerges when that new work is added to the original story. Often this is coupled with a feeling that no one really knows what good looks like. The team starts to feel like they are working towards a moving target. It will only be a matter of time before the “When will you be done” questions start. Think for a minute about how it is possible to formulate an answer. Every time the team asks for feedback, more work is generated and so the goal has changed. Yet they are asked to say when work, which they may not know about yet, will be complete.

Work is blocked by external dependencies

Sometimes someone outside the team has a stake on when a story is complete. It may be that you are integrating with a third party and they have onboarding activities. Perhaps there is an external customer that has a final say on whether the work has been delivered to the necessary standard. The important thing to realise is that you cannot control this decision making and it is highly likely that your timescales will not align. The best thing to do is to accept it and then put in controls to minimise the impact on you.

There are a couple of things you can do to take control.

  1. Understand the requirements of the third parties upfront and ensure that this is factored in when creating the stories in the first place. This may feel like up front design but you are doing just enough to mitigate the risk of a delay in the future.
  2. Don’t “leave the bonnet open” on work whilst it is outside your control. Deal with feedback whether that is good or bad as new work coming into the backlog and deal with it on a priority basis.
  3. Minimise external dependencies by only having them when you absolutely can’t avoid them or where they add value to solutions you deliver.

Quality defects stopping work being completed

In this situation, the work has been done and the team’s tester is working on it only to find a quality issue. The story goes back to the developer to be fixed. Subsequently the tester picks up the work only to find more issues and repeat.  When this has been happening for some time, e.g., it is a reoccurring theme in multiple stand ups, the team needs to try to understand why things are bouncing around between two team members. Are the developer and tester working together on the story or is the developer “throwing the work over the wall”?  Are the defects being raised related to the changes being made under the story in question or are they coincidental. Are the developer and tester on the same page as to the quality metrics for the story?

So what?…

Never-ending stories are bad because they harm your team’s predictability. They are a black hole, they consume effort and people. No-one in your team is really sure when they will be complete. If you are working on one it can be very demoralising. Personally, I am motivated by finishing things but never-ending stories can really feel like a ball and chain, never allowing you to finish and never enabling you to move on to other things.

When you look at the examples I give there are a couple of ways to avoid never ending stories

Firstly, ensure that you are aware of the work that is being created. Whilst it is normal to create some new work when delivering stories, you need to decide the point at which you need to call it out, surfacing it as new work in the backlog and letting the PO prioritise it rather than absorbing it. If you are not doing this during a sprint, maybe when the story is carried over at a sprint boundary, this would be a good time to ask yourself if the story should be broken down.

Secondly many of the problems with defining the scope and boundary of a story could be resolve by investing time in defined acceptance criteria at the start. You may use a Story Kick-Off for this. The acceptance criteria could describe how the story should function, they define the quality criteria for the story and the expectations of third parties. And let’s not forget that we should be aiming to avoid large stories, breaking them down along their natural seams in order to keep your team predictable and high performing.

Azure, Cloud Service & Reserved IPs

Azure, Cloud Service & Reserved IPs

Azure is pretty good at getting you up and running quickly. You can get from nothing to a solution in production very quickly. Whilst this approach definitely reduces time to market, it can introduce growing pains along the way. Let’s consider Cloud Services as a specific example of how growing pains might manifest themselves.

When you create a Cloud Service you get two IP addresses, one for each slot, Staging and Production. These are allocated from a huge range Azure manages for each region and you have no guarantee of which IP you’ll get. When you’re setting up your Cloud Service you probably didn’t worry about that. As time passes and the solution matures you may have used those IP addresses to create firewall rules to your databases in Azure and perhaps even giving them to third parties in order for them to be whitelisted to allow your application to access another service.

Now the specific IP addresses that were allocated at random by Azure are now critical to the success of your solution. And guess what, those IP are not as secure as you might think. If for whatever reason your Cloud Service is deallocated, the IP addresses will be lost. When you recreate the Cloud Service it will be allocated a new IP address. All of your firewall rules now don’t work. That might not be a major problem for your own rules which you can hopefully change rapidly but it might be a problem if you are working with a supplier that has a 2 week turn around SLA for “minor changes”.

This is where Reserved IPs come in. They are a means to control the life span of an IP address by effectively taking ownership of it in your Azure subscription. Now Azure will never reclaim an IP Address whilst it is reserved in your subscription. The following PowerShell command will create a new reserved IP address.

New-AzureReservedIP –ReservedIPName very-important-ip –Location "UK South"

And this command associates the IP address with an existing Cloud Service.

Set-AzureReservedIPAssociation -ReservedIPName very-important-ip -ServiceName MyBrilliantService

However, we might already have a Cloud Service and its IP address has become important. Changing it would cause unacceptable problems. Luckily it is possible to create a reserved IP from an existing cloud service. The following Powershell command creates the reserved IP using the IP address of the Staging slot of a Cloud Service and also creates the association between the reserved IP and the Cloud Service

New-AzureReservedIP –ReservedIPName very-important-ip –Location "UK South" -ServiceName MyBrilliantService -Slot Staging

A couple of notes about these commands

  1. The -Location is the region in which the reserved IP will be created
  2. The -Slot is an optional argument on these commands. It lets you target either the Staging or Production Cloud Service deployment slots. Production is the default.
  3. Reserved IPs are a “classic” Azure feature. As such resource groups are a meaningless concept. You’ll see all your reserved IPs deployed to a Default resource group.
  4. The first five reserved IPs are free but you should be aware managing more than this is not. You are charged based on the time you hold on to an IP address, which is in effective, to dissuade you from holding on to a large number of publically routable IPV4 addresses which are increasingly become a limited resource.

Let’s talk about deallocation. Over the lifetime of your solution your architecture will evolve. You might need to move an IP address from one resource to another. You may want to release IP addresses that you no longer use. Once you have an IP address reserved you own it until the reserved IP resource is deleted. The only way it can used is by creating an association. To use it elsewhere it must be deallocated from the original resource and associated with the new resource. It is important to note that during the process the original resource will receive a new IP address from Azure’s pool.

When playing around with reserved IPs I noticed a couple of behaviours that are worth noting.

Firstly, once a Cloud Service has a reserved IP you must specify its name when deploying the Cloud Service. Remember that the name of the IP should map to the one used for the particular slot. You do this by adding a NetworkConfiguration section to the service ServiceConfiguration file

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="My Service" xmlns="" osFamily="4" osVersion="*" schemaVersion="2015-04.2.6">
<Role name="MyRole">
<ReservedIP name="very-important-ip"/>

I found when the reserved IP was not referenced I received the following error when deploying. I believe by not specifying the IP the deployment process assumes you are changing the IP which is not allowed

Set-AzureDeployment : BadRequest: A reserved IP cannot be added, removed or changed during deployment update or upgrade.

Secondly if you added a reserved IP to one slot of your Cloud Service you must also add one to the other if you want to be able swap the deployment slots. You’ll get this error if you forget.

Move-AzureDeployment : BadRequest: Cannot swap VIPs when only one deployment has a Reserved IP.

Finally, as the number of Cloud Services in a particular environment grows and the number of environments increases the management overhead for the individual reserved IPs increases greatly. Let’s say you have 6 cloud services in 4 environments. That is:

6 cloud services * 2 deployment slots * 4 environments = 48 reserved IPs

In that case it might be better in the long run to build up a VNET with a subnets for each environment and then have a Virtual Network Appliance presenting these network to the Internet on a smaller range of IPs.

For further reading on Reserved IPs take a look at the following links.

The state of “Not Invented Here Syndrome” in 2017

The state of “Not Invented Here Syndrome” in 2017

Development teams often build up high levels of trust internally due to the nature of the constant collaboration between team members.  Whilst that internal trust increases and increases, it can cause a lack of trust of outsiders whether that be 3rd parties or even other internal teams. So, when there is a genuine case for reuse there is often a strong argument against it. A common one is that the high-quality standards of the team can only be assured if code is written in house.

And why not. Developers like writing code, therefore given the chance they will write “all the code”. But code has a cost in terms on maintaining a solution over time. And we will have to support the solution because software isn’t written once then forgotten about, it continuously evolves. And let’s not forget that writing scalable, reliable and adaptable distributed systems is hard.  Who really wants to be debugging a custom load balancing solution when your system is on its knees and customers are beating down your door. Why invest the next couple of months building yet another custom security solution when your competitors seem to be releasing new features every few weeks.

The IT industry is seeing trends that will hopefully consign that old insular mindset to the history books.

Cloud computing offers, amongst many other advantages, the opportunity of offloading complexity on to some other party. Why worry about heating and air conditioning in a custom data centre when all you really need to do is build a website? Economies of scale means that costs are substantially reduced but you need to remember that cloud offerings are built for the masses and if you don’t fit then you may not get the benefits you expected. Cloud solutions such as Azure and Amazon Web Services practically offer a menu of services that you pick based on your requirements for ease of use vs the flexibility and control that you need. At the extreme, serverless computing promises that you can deploy and run code in the cloud without ever worrying about how the underlying infrastructure will be scaled to meet demand.

There is a trend where many companies are reinventing themselves as tech companies – Netflix and Amazon are just a couple of examples of companies that in order to be disruptive in their particular marketplaces transformed themselves into technology companies. Over the last few years this has reached a tipping point and now many organisations are trying the same thing and expecting the same results. Whilst it is true that IT is fundamental to many business models and being technically savvy as an organisation has a key role to play it is unlikely that everyone needs to code their IT from the ground up.

By looking at the first movers in that space you see technologies being developed in house to solve a particular problem and then shared back to the community. Google created AngularJS and Facebook the Cassandra NoSQL database. Today anyone can pick up these projects for their own use and perhaps more importantly they can contribute to them allowing them to evolve independently.

So, my vision of a team that is successfully avoiding NIH Syndrome in 2017 is one that

  • Has a wide understanding of the technology landscape
  • Does not exhibit siloed thinking about technology stacks, particular products or architectures
  • Has the time and space to try new things
  • And is encourage to contribute back into the community that they take from.

Reusing open source software is not like picking apples from somebody else’s orchard. It is a two-way proposition. You use an open source project to enhance your own product – usually to save cost and time. Therefore, you should invest some of that time back even if it is to simply fix bugs or answer questions on Stack overflow. And here in lies the challenge. Many organisations do not yet see the value of reinvesting in the community that bootstrapped them to where they are today and are so single minded they cannot see beyond their own immediate business pressures to deliver more features. Whether this approach is sustainable – I’m not sure. But as more and more companies transform into technology companies the cream of the development world will come to expect certain values from their employers and as you know the cream rises to the top.





Permission, Ability and Skills

Permission, Ability and Skills

It could be argued that the primary purpose of a software developer is to provide solutions to problems. Problems are presented in the form of requirements or user stories and it is the software developers job to provide a solution. They provide a solution with the tools that are available and within the constraints that exist within the organisation in which they work. Normally this is done unconsciously and we don’t stop to think about it. We open of our IDE of choice and start coding.

It is only when we start to encounter what might be considered more difficult problems, we start to see the limitations of this approach. What happens if the problem is that of building up a continuous delivery approach for your team or providing a level of disaster recovery for your product’s infrastructure.

Torturous Analogy Time.

Let imagine that the problem is that I need to travel from London to New York for conference. I have permission from my organisation to do this but I have no other help.  Let say I work for an aircraft manufacturer and they have a plane sitting outside ready to be used. They don’t want to waste money on buying a standard airline ticket when they have a £multi-million asset sitting outside. (I told you this is torturous!). So now I have the ability to get from London to New York but that still isn’t helping me because I can’t fly the plane, I don’t have the necessary skills.

In order to solve the problem I need the permission to tackle it, the ability, through technical support and the skills to use that technology to solve the problem at hand.

In software development we’ll nearly always have the permission and tools but that is not always enough to solve the big problems such as those a mentioned above – building up a continuous delivery approach for your team or providing a level of disaster recovery for your product’s infrastructure.

Solving the big problems often requires organisational transformations which require at least three aspects to change – people, process and tools.  Simply having the tools is not normally enough.  It like having the plane without the skill to fly it. As technologists, we want to believe that it is the tool that provides the solution to a problem, but it isn’t.

We are doing ourselves a misjustice really. We provide the skills that ultimately solve the problem. The technology simple provides the ability to bring those skills to bear.

Selecting the right tool for a job

Selecting the right tool for a job

Tooling, as it turns out can be a very emotive subject. Everyone has their favourites but often we find ourselves in situations where we don’t get to choose. And even when we do get to use our favourite, in all likelihood there are others using it under duress, waxing lyrical about the superior feature set of an alternative product and how pleasant life would be if only we were using that instead.

I have a few principles, guidelines or rules of thumb when it comes to tooling, and the tension, conflicts and friction it can cause across a team

Understand what you are trying to achieve

Before you even start thinking about tooling or any other type of software you need to understand what you are trying to achieve and why you think a tool might help. If you can’t answer that question than how can you expect to select and evaluate a solution.

Let’s say you want to select a tool to assist your software delivery. You might have team members in different locations so simply representing work items as sticky notes on a wall does not cut it. Therefore, the team needs something that enables the creation of work items that are visible across all team members. You also might be finding it hard to understand what work is being done, so you want something that makes it possible to see which work items are currently being worked on, and provide an indication of who is delivering a particular piece of work.

Once you understand what problems you are having you can determine what is required from the tool.

Understand how the tooling has been designed to solve a particular problem

For the software team building a tool, a problem such “as running a SCRUM team” is a wide problem space. That team will have had to build an understanding of how their software solves that problem, perhaps looking at best practice or by analysing a number of past successful projects. They will have also made their product adaptable and configurable in order to attract as many customers as possible.

When you look at the tooling from different vendors you may see that they may have solved the same problem in a different way. This might have been for a number of reasons which include understanding the problem differently, prioritising different features and trying to differentiate themselves in the market.

How you see the problem space and how the vendor does is likely to be different. They will see it from a wider and generic perspective, and you will see it from the narrow, specific point of view of the immediate problem you are trying to solve.

Adapt in both directions

Once you understand the problem you are trying to solve and how the chosen package aims to solve it, both sides need to compromise.

In an ideal world, the software would solve your problem, immediately, out of the box or maybe with some minimal configuration tweaks. More realistically you should expect to do some configuration to tailor it to your circumstances. It is likely that products will be design with this in mind.

However, if you are finding that you are having to warp the product out of all recognition to get it to work for you, even when you are both working in the same problem space, you need to ask yourself some searching questions.

  • How much effort, time and money is required to maintain heavily customised software
    If this much customisation is required are we really in the same problem space

I have seen a number of teams warp a software solution completely out of shape without asking themselves whether they should change their ways of working to better suit the software. It is highly likely that the software vendors understand the problem space better than you and have created a tool that deals with the majority of typical usage scenarios so why are you different, why are you not typical?

Standardise where possible

Standardise in this context means using the selected product across teams, business units and even organisations. This means you get the benefits of scale. Lessons learnt by one team can be shared by others. A standard solution also means that operating costs are likely reduced and there are only one set of administrators and one set of hosting costs.

This also may mean you don’t get to choose. The software might already be available so this is the default choice.

However, many organisations miss the next part. This is that choice still exists if the product really does not work in a given situation. Unfortunately, the lure of cost saving and efficiencies drown out the small teams who are greatly hindered when forced to use the wrong tool for the job.

Having a standardised solution is not the end – it is the beginning. The usage of the software needs to be continuously reviewed to see if it is still the right solution. The product needs to be upgraded and patched and there should always be an eye on the other solutions in the problem space. An alternative product that was previously discounted may now be a better fit.

Accept the choice

And finally, if the choice doesn’t go your way you need to accept it. You need to get behind the choice and make it work for you and your team. As technologists, there are always going to be better choices. It is often a case of the “grass is always greener”. And maybe you’re right this time but maybe you’re not. It is all too easy to fall into a trap, where you believe that a tool will solve all problems. Usually what happens is that the tooling will be switched only to find that you have all the same sort of problems. It wasn’t the tooling that was the solution after all.

In my experience the problem usually lies with people before it does with software. If your people can’t solve your problems, then you should not assume that software will.