On Teams

latest-small-64Software is so often built in teams that there a whole bunch of theories and statistics that have been generated based on the various aspects of team work. What’s the best team size? How do teams work best together? How often should they meet? and on and on…

What do I know about teams, well not much to be honest, I hate them for the most part. The problem with teams is that as soon as you put more than one person on a project or module you lose the productivity of N people. For instance,

1 Person Team = 1 productive

2 People Team = 1.9 productive

3 People Team = 1.7 productive

And so on. Each person you add to a team doesn’t add a full person, and it gets exponentially worse – the bigger the team, the less you’re actually going to get out of each person because they have to cope with communication, personality and view point issues. Engineers are a valiant lot, they love to debate and make their case. Thats brilliant! Apart from when you’re trying to get something done.

Of course, sometimes the project is just too big to allow one person to fit it in their head or get it all done in time. Bare in mind the above – thats not as often as you’d expect, that said we all end up having to have teams. So what can we do about it?

Well Scrum would tell you its all about structured regular communication. Waterfall would tell you its all about designing everythink to infinite detail up front to prevent any sort of discussion. I think theres a few tips that can help:

  • Module/Section Ownership – each team member “owns” one of more modules of the code. i.e. it’s not a free for all within that module. This can sometimes lead to bottlenecks, but also means that one person has authority and responsibility for one section working.
  • No Hippie Communes – this is software, this is business, this is work. It isn’t about everyone feeling great about each and every decisions. Make sure that some one is in charge and has the authority to push through lengthy discussions. A lot of time can be spent trying to find an answer that everyone agrees on when the impact of the decision doesn’t warrant it.
  • Think Personality – Engineers are awesome, the personality range is huge, but when you’re building a team remember that. The personality interactions are often more important that the technology implications on the road to getting it done.
  • Enforce Caring – I know, that sound silly, but set the example and show that you care about your modules. Be defensive. Be forthright. Try to encourage others to understand responsibility for their own code makes them accountable for success and failure. A team that gives a shit is always a success. A team that doesn’t may succeed through luck.

Software emerged from a lot of open minded, free thinking individuals that some may refer to as tree huggers. Unfortunately that mentality creeps into our every day developer lives. Good teams argue and defend, but they don’t do it for very long.

On Technology Choices

latest-small-64There’s a nasty habit in software to choose technology based on what’s the latest thing to arrive. You can see this in tools (e.g. GIT) or languages (e.g. Ruby) or libraries (e.g. AngularJS). The thought is because a technology choice is new, it’ll be better than the one before it – and in all honesty, a lot of the time this is true.

However, avoid being dependent or biased based on the relative age of a technology when making choices. Pick the right tool for the job is the rule we’d all like to live by, but be aware that it’s in a technologist nature to pick the newest shiniest toy in all cases.

When a new technology is born it’s sometimes to fix a perceived problem in existing solutions. Sometimes this is a great thing. Take GIT for instance, SVN was hurting distributed teams, merging and branching were painful and slowly but surely developer’s approaches were being limited by the tooling they were using. So we all started moving to GIT.


Does a new technology come without penalty? The answer is flatly NO. There is re-training, the new gotchas that come from a new model and the overall cost of moving from one to the other. Think for a minute, were the problems that the new technology was solving actually problems you were encountering? Were you using SVN with distributed teams? Were you using lots of branches and lots of merging?

The point isn’t that picking a new technology is bad, rather than yet again you need to think for yourself.

  • Is it going to help?
  • Is the older technology going to be updated to fix the problems you’re experiencing in a lower cost time period than the one you’re moving to?
  • Are you just storing up a problem for later?

For instance, I’ve just gone back to Flash/Flex because it solves a need for me. Yes, it’s old technology (relatively) but it’s the best tool for what I’m trying to achieve today. Is it bad because it’s old? No. In fact, it’s been exercised so heavily due to it’s age it flips round and becomes a good choice.

Know why you’re choosing the technologies you’re choosing, if the primary reason is that it’s new (and be honest with yourself) then think again. Alternatively if you have infinite time and people knock yourself, hell we all like to play with new toys!