Contract Negotiations

Its a common situation for developers to end up with a dependency problem when they're looking at their sprint task board.

"We need to do that before we can do this, and we can't start on those until that bit is done"

This is often blamed on poor planning or on some other team who haven't delivered, sometimes that is the case, but sometimes the sprint board is actually telling us something important about our code.

Coupling Up

The inability to develop parts of the code side-by-side is a pretty good definition of tight coupling.

If you find that your having to organise your sprint tasks in a specific order, and more importantly in a sequential order, you should consider if this is because the classes involved and too tightly glued together.

Fight the Good Fight

Another important aspect to consider if your having trouble organising your tasks is will it always be like this every time we change this area of the code?

Good code design anticipates change and has a plan for making it as smooth as possible, if changing one particular area strikes fear into your heart and always leads to a messy scrum board this could point to some inherent problem with that portion of the code base. 

 Design By Contract

So what if you have established that your sprint board is a mess because its an accurate reflection of your code, what can you do about it?

The answer is interfaces.

If your classes are interacting with other concrete classes you are doomed to operate in a sequential manner, but what about if before we started coding anything we gave a little bit of thought to how these classes might need to interact.

If we defined these interfaces before we start coding all of a sudden we can code classes in parallel, providing we all agree to abide by the contract the interface describes once all the classes have been written the system will work.

Not only have we managed to speed up development we've also gained all the other advantages interfaces bring.

I know my class is built for change because I wrote it before you'd even finished yours, that shows me I definitely do not depend on the implementation details of your class because they didn't even exist.

Not only that I even have good unit tests that show my class works with anything that has agreed to honour the same contract.

When we next come to make changes to this part of our system we will once again be able to edit these classes side-by-side with no fear. 

Can't I Just Get On With It

Some will tell you its a waste of time to put all this effort in to defining interfaces.

"That's Just Overkill"

"We'll look at that if we ever need to change it"

We'll I find it a slightly strange argument to say its a waste of time to put some thought into something.

The time you take to think about the interfaces upfront will be repaid with interest as you continue to develop the system from the parallel development and built in plan for change that we've already discussed.

If defining the interfaces does truly take a long time all this proves is your system is complicated, the time saved in not thinking about it is simply a false economy that normally goes by the name technical debt, at some point you will be forced to think about it and it may have gotten even more complicated now you have some code that wasn't thought through at the beginning.

Re-factoring always takes longer then coming up with a good design in the first place and you can bet the point you need this re-design will come when you under pressure to ship.

Don't assume that your code base and problems in your sprint planning are separate, very often they are more connected then you might think, always be on the look out for signs that your code may need changing no matter where they might come from.