The human brain is a marvellous thing.

I’ve been typing a lot today, so much so that my thumb has started to hurt. So I’ll keep this short.

What amazes me is that I was able to think ‘OK, so I’ll just stop using my right thumb’ and I then continued typing for the next hour without using it, without creating loads of mistakes or even slowing down too much. How exactly?

Working on the rules engine for our insurance software today makes me appreciate just how extraordinary it is that the brain can accept rules into the subconscious and then start processing them without so much as a hickup, any formal, lengthy definition, or any forethought or planning. The rules we give our brain on a whim can cover just about anything and almost always work perfectly. In fact, we can make them work better by thinking harder: if I want to make sure I type 100% correctly without using my thumb I can do it, or I can type really fast and the rule is only loosely applied. It’s like there’s an Importance level we set for these ad-hoc rules.

They even work at times like this where they affect a completely subconscious activity like typing. Does that mean I could learn to breath differently? Probably. There are plenty of people that learn to walk in silly ways.

I’m certain that with our rules engine we need to emulate the brain; that’s our real competition, not other software systems.

Never add resource to a late software project…

Many of those new to insurance software development assume that adding programmers to a late project is the right thing to do in order to finish as quickly as possible.

WRONG! This is almost always the absolute worst thing you can do. It will not only not help but will actually make things worse, often much worse. You’ll probably never work in software again.

Why?

The reason for this is simple: communicating software ideas on even the simplest project is frightfully expensive and rises exponentially with the number of team members.

In our industry, even the most elegant insurance software is complex at its heart.  We deal in increasingly complex mathematical and emergent algorithms; we can’t get everything across in a single utterance, this is actuarial science.

With each developer you assign to a project (at any time in its lifecycle) you increase the vectors of communication, often considerably, and the average communication burden for each team member goes up.

To explain more clearly…

A 1 man team communicates within her head, so no problem there.

In a 2 man team, there are two vectors for communication. When Hildergard (eh?) writes code that Bartholemew (who?) doesn’t understand, he interrupts her flow to ask about it, and visa-versa.

In a 3 man-team, there are 6 vectors for communication, whilst in a 5 man team, there are 20 vectors for communication. When Jonah writes a new routine that he wants people to use he tells the team leader Archibald. Archy tells everyone to refactor their code to use the new routine but they’re all very busy, and it’s not the first time someone has told them how to make their lives harder. Consequently, many of them forget, realise too late, can’t even remember where to find the routine or how to use it, or never took their headphones off in the first place. Consequently, sporadic conversations break out between all team members: Jake and Ben talk about optimisation, Phil and Lindsey argue about nomenclature, Ben and Lindsey agree that Roger, Jake and Derek have usage all wrong. In the end everyone speaks to everyone about it, and after all the chinese whispers subside, Jonah wishes he was in a 1-man team like the good-old days: no one has used his panacea routine properly and some not at all. Now he has to rewrite everything, and hold a mini conference to sort things out. Again. Just like yesterday, which was his birthday and nobody remembered. Jonah decides to cut his losses and quits.

The Theory

Fred Brookes (the immortal God of software development theory), defines the number of vectors thus, where n is the number if developers on a project, and v the result:

v = n(n – 1)

So, with a 6 man team there are 30 vectors for communication, and with a 10 man team *gulp* there are 90.

So what?

When you add techies to a late project, you screw everything up. Software development isn’t like building a house, it’s much more like designing it, only harder. Let’s say you add 2 people to a 3 man team, right at the end of the project. At this point your programmers are working day and night, sleeping under their desks and eating with one hand. The team leader is living and breathing code, has a caffeine drip and never stops muttering to himself in binary. He’s getting email questions every second. That’s when you choose to increase the chat traffic vectors from 6 to 20 and bring in a couple of clowns who keep asking stupid questions. And when they finally do some real work, they bring the whole precious house of cards fluttering to the ground. What you’ve done here is invite a couple of wet monkeys in to dance on the architect’s blueprints.

You pay peanuts…

The thing is, even programmers sent by God Himself^[i] need things explaining if they’re new to the project, and even then they still screw things up for a while (a year usually). That’s even if you have great documentation (and you all obviously have that… right?).

You can actually make the project go backwards.

What?! Yes, if you get a situation where the team doesn’t have time to explain everything to the newbie, he starts guessing, and changing code he doesn’t understand.

If your poor junior is left to work on rating matrices or something that affects billing or reports, you can kiss your insurance operation goodbye. By the time you find the bugs, it might be too late.

Holy cow. Whatever will I do?

1. Don’t add programmers to a late project (well yeah).
2. No really, don’t ever do it.
3. Study software development theory: start by reading this and this and this.
4. Set realistic deadlines (easier said than done – more on this in a future post).
5. Encourage group communication; ever heard of scrum? It’s important to have well organised, poignant, productive group discussions.
6. Expand your software ambitions horizontally. This means putting new programmers on new projects, creating complimentary projects that all work perfectly and get finished on time. Wise men know nothing can be done fast. It becomes another thing entirely when done differently, faster. Piling resource onto something you want done faster than it can be done is silly vertical horseplay, it will end in a heap of burn outs and angry developers who no longer trust you.

Show me the money. What’s the quick way?

Hmm, there’s no pleasing some people. Well you could always take a leaf out of Google’s book: buy your programmers pizza, make the vending machines free, and give everyone a share in the profits. Make the office so friggin’ cool they forget where they live. Take all the door knobs off and put in a disco ball. Never run out of coffee.

Did you like this post?  Leave a comment below…

* Like Einstein said, _He_ doesn’t play dice. God built the world in 7 days with C++. Being perfect, he has no need for managed code.