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.

BUT WAIT!

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!

On Languages

latest-small-64So many things in software become religious wars, languages is probably number one. Which language should you use for any given task? Which language is generically the best? Which language is fastest/smartest/structured/extensible/prettiest?

Which languages have I seriously coded in? Well, lets think, Basic (C64/Spectrum/ZX81), ASM (Z80, 8086, 68k), Pascal, Forth (White Lightening), C, C++, Eiffel, Java, PHP, Javascript, Objective-C, Visual Basic (yes really). Which languages have I had to work in now and again, Shell (CSH, BSH, ZSH), Perl, TCL/Tk and probably plenty of others. Which is the best? Who knows? I use Java most but thats through familiarity not through any sort of belief it’s the best choice?

And what makes it a language? Does XML or HTML count as a language? God no! Why? Languages to me, mean some sort of branching or decision making. So a specific XML dialect could be language, but for god sake, HTML is not a programming language. The next resume I see with it listed under programming languages I’m going to burn!

The answer? What language is the best? Well who gives a flying ferret? You’re here to get the job done, you pick the language which suits based on all sorts of factors – some of which have nothing to do with engineering.

  • Is it fast enough?
  • Does it integrate to whats required?
  • Does it run on the platforms you need it to?
  • Whats the library support like for thing things you need to achieve?
  • Whats security like? Patching? Bugs? Flaws?
  • Do you know it?
  • How long will it take to get used to it?
  • Does anyone else know it on your team?
  • Does anyone else know it in the company/support department?
  • How soon does this thing need to be built?
  • Will the target customers run it in their environment?

So the first few up there are certainly engineering thoughts, but what about the rest? Is anyone actually going to be able to support this thing you build? Are customer’s going to be able to use it? The minute you start working for bigger companies there are so many policies to comply to – you need to consider it all.

As always, I’ll end with thing for yourself! Don’t let me or anyone else give your a crutch to rest on. Consider all the factors but limit yourself to simply which is technically the best – consider everything and don’t let your religious bias cloud your way.

On Naming

latest-small-64So, why “Kev on Software”? As you can imagine the first bit is easy – my name is Kevin, but why “on Software”. Back way back when there was a blog called “Joel on Software” – by Joel Spolsky. He wrote passionately about what made good and bad software, and where he saw the pitfalls. It’s been many years since I’ve been regular reader but most of his opinion pieces stick with me, even if I didn’t agree. I think thats what his blog taught me most, that thinking for yourself is the key to everything, especially in software. Guidelines, methodologies, courses and approaches are all great, but if you stop thinking for yourself you’ve already set up to fail.

As I was thinking about the name, it occurred to me I care about naming in software more generally. When you’re building code, or documentation or even marketing material the names you use mean everything. The right name makes something instantly memorable, the wrong name can be useless or in the worst case mislead. Consider the following:

I have an object that contains a set of Book objects. If thats it’s only description in your system, then BookList makes a perfectly good name. However, where in your system is a collection of books meaning really only a collection of books?

Is it a Shelf? Is it a Catalog? Is it a Library? Does it really matter? Well yes, it can do and this is where the thinking for yourself bit comes in.

  • Who is reading this code, is it only ever you or are there other people maintaining it?
  • Does the context mean it doesn’t have all the properties of a list, e.g. can you add and remove items? (Yes, you could for for ReadOnlyBookList, but now its getting silly)
  • How long is this code going to last, does the design of the interface to this class really matter at this stage?

Reading the above you’re probably saying, but you’re not arguing either way, and that’s correct. Think for yourself!

If the code isn’t going to last more than a day, who cares what it’s called? Why waste perfectly good cycles on a name that will disappear shortly. That said, are you sure it’s only going to last that long – and are you willing to put the time into change it (and it’s ripples across the code base) if the code does end up lasting longer?

Is the addition of methods in the interface for a BookList going to imply something outside of the context of the class? Is removing items from the list possible in the context, and if not, is having the method going to mislead and confuse?

Are you the only one who is ever going to maintain this code? In which case does it really matter given you’re going to keep the whole thing in your head anyway? Are you sure?

The above questions, and many others, sound like a lot of thinking to do as you’re endeavouring to code away as quickly as possible. However, once you’re thinking about it every day as you code, it’s split second decision making – that you don’t need to cross check with every guy around you and his dog.

You think, then act. If a discussion does arise later then you know why you made the decision and if things have changed you refactor.

 

Why now?

latest-small-64So here we are, another day, another new blog – but this time its personal. I’ve been developing software a while, 20 odd years commercially and if you count all the years I spent as a kid we’re talking 30 years.

I’ve watched software turn from something a few people knew how to do, to being a skill, to being a formal method, to being a discipline in its own right and finally being an integral part of every enterprise business everywhere. It’s been fun and I thought until recently I didn’t really mind how it was done as long as I still had a job.

Then it happened, I became a manager, I watched as teams of people I looked after did things different ways, and believed and subscribed to different methods than I did. No, it didn’t scare me, its positive right? Well yes it is, but then you start seeing the time thats so important to your business disappearing down rat holes of belief and opinion. Remember, when you’re writing software it shouldn’t ever be just for “the sake of it” or worse still as an “engineering exercise”. Commercial software serves the business it’s written for, like it or not, as a software developer you’re a cog in a large machine thats trying to make money.

The reason for this blog? I posted this on facebook today and got a score of replies about software. I didn’t realise but I actually care, not sure when it happened, but I do and I’ve done this stuff, a lot. This blog documents my opinions and hopes to drive discussion if not agreement.

fb1