And scaling isn't performance, but thats a separate rant.

The complexity of software dosen't increase linearly with its size. If its very well written then you might got close but at some point everything will end up talking to everything else, then your screwed. Code can be split up into libraries and managed carefully but its still far to easy to reach around interfaces and do something bad. At its worst everything ends up talking directly to the database.

Slicing off a lump of functionality and sticking it into a service, especially if its a restful one has a knack of making you have a think about what you are trying to achieve. You can start thinking about giving the service its own independent storage. Maybe using an alternative and more appropriate technology. The dependencies and backwards compatibility are still a pain, but they were there anyway just hidden by other pain.

Imagine a system composed of 10 dice with 6 sides, how many possible combinations? A lot, I'd work it out but I can't be bothered its that big. Take that same system and slice it into 10 subsystems each of which can be in 6 very well understood states.

I know which one I'd rather test.

This will only work if they are totally different systems, the only interaction between them can be through the tested interfaces.

Why isn't it for performance and scaling, well you just picked up a load of network chatter that you are going to have to deal with. Most likely with some caching, which can be fun. But I think that its a worthwhile compromise just to separate some concerns.

The logo for Mostly Monkey is done, i'm really pleased with the results. More to follow. Feel free to let me know what you think of it.

So recently I decided to get a company in india, brickwork, to do some of the boring bits of a project for me. It mostly consisted of doing research into affiliate programmes. There has been some confusion but I think that we are getting there. Considering I paid for 5 hours labour I think that they have ended up doing about twenty for me. Still waiting on the final results so we shall see.

The key to it all; say exactly what you need them to do. If there is a process go through it literally click by click. Do not assume anything, if you are coder then imagine writing a script to do the job with decision points clearly highlighted along the way.

I'll update when I've got the final results back, hopefully they will make more sense this time.

Iv'e just finished reading Re-Work, the 37Signals book that encapsulates their philosophy. Its written by DHH so it doesn't exactly pull its punches.

One of the chapters is about the work environment, it specifically talks about not treating staff like they are kids. Elsewhere in the book there are references to having people who work instead of delegators.

I think that the two ideas mesh together nicely. By giving people the ability to make decisions for themselves. You make yourself less important then if they are constantly having to come to you to ask for permission. At that point you might have to explain exactly what you do all day, or not. Maybe you just get to be able to work normal hours again instead of spending all day answering emails and then doing you day job outside of hours when you are tired.

Tim Ferris talks about the same ideas in the Four Hour Work Week except that employees he has outsourced most of his business to other companies. He told them to speak to each other and if they could resolve any problem for less than $400 to get on with it. At the end of the month he reviews any decisions made and sets new guidelines to inform decisions.

The essence of this treat people like children and they will act that way.

It seems that a lot of emphasis is placed on Definition of Done in SCRUM. Its generally the development team that are going to decide on this and communicate out, as a set of rules for them to abide by you can potentially change them every sprint or project. Hopefully to improve them.

The really complicated on is ready for development, this has to be communicated clearly to people outside the team. It will take them time to get their heads around it, so you don't want to be changing it every five minutes. Ready for dev is also something that is seen differently by different members of the team.

The absolute most important thing to remember is that for a user story to be ready a developer must be able estimate the complexity of the story and then start work on it. This absolutely has to be done without a raft of assumptions being made. If the writer of the user story needs to be consulted its not ready for dev.

There are two approaches to dealing with this:

Stick to the rules: Push back anything that isn't ready even if the sprint is only partially full. Warning this will end in tears.

Work together: The less us and them the better. Before the sprint planning meeting have a chat with the person writing the storys and go through some of them to make sure that there is enough detail. Encourage to flesh them out where needed.

The idea is to wean people off option two and onto one.

Also many thanks to the mate that I blatantly stole this idea from...