Software is a Total Mindset

Like every other team sport, software requires that everyone is pulling in the same direction.  I know, I’m shocked at the deep and original thinking that went into that one, too.  But oddly enough, it’s something that in my short and sheltered experience, that’s really quite difficult to achieve.  The more people in a given team, the harder it becomes.  Once again, no real surprises there.  But it’s something that is usually not outwardly stated.  Agile teams are usually recommended to be kept small, but the reasoning behind that is usually restricted to factorial communication network explosions.

But it’s more than that, isn’t it?  Getting software developers to all work together, try as we might, is actually a bit like herding cats.  A quote which I like to trot out every so often is “An Engineer without a problem to solve, will readily create one”.  Though I’d like to make a slight adjustment to that; An Engineer who’s bored of solving a problem will readily move on to something more interesting.  So what if a particular team is bored of solving the problem that the business has told them is the most important to it?

I worry that wandering off into the periphery of acceptable work, then successfully convincing the project (and probably themselves – I’m not implying malicious intent here) that they’re doing their absolute best to deliver the project is going to have a detrimental effect on team morale.   It leads down a long and winding road, working hard to deliver something which doesn’t fill one with pride, whilst also constantly having to fight to keep the project police away, which is exhausting.

I used to be in a team which did and still does exhibit this behaviour.  I would like to say that I got out of it because I saw a team in distress which was beyond my junior powers to help turn around, but that would be a blatant lie.  I left the team (which I truly enjoyed working for, even if it was some seriously hard work at times) because I wanted some experience in technologies with some slightly more global prospects (and it worked too – I’m heading to Austria next month).  Now, I would like to be absolutely clear here, I do not in any way think that the team in question has malicious intent.  They are working extremely hard to deliver that which they think is best – but their powers of reasoning has been solidly skewed by a series of unfortunate decisions, which all seemed to be the right thing to do at the time, but appear to have all conspired against this team to really hurt it.

The main decision which I think hurt it, was the risk-averse decision to continue using more or less the same hardware platform.  Terms like flogging a dead horse were certainly thrown around.  I understand the reasoning behind it, but it means that the problems this team have been asked by the business to solve are already effectively solved, in a free and open source fashion.  So most of the work they have been attempting to do is bring the old code forward to this very similar platform alongside making it jump through hoops to perform tasks which it isn’t really capable of and certainly wasn’t designed for, when the original was envisaged more than 10 years ago.  That is a truly depressing set of criteria.

In a perfect world, I suppose, those constraints could be forgotten and everyone would merrily get on with it.  But add a couple of strong personalities to the mix, heavily fluctuating leadership and their understandable reaction was to then question how long this codebase must be maintained for (and will the underlying platform increase in power significantly during that time?) and suddenly every single task can’t have any compromise – it must be absolutely generic and have massive scalability.  Two very difficult things to achieve well, together in software.

I’d like to take a moment to explore how these technical limitations have affected the slightly fuzzier side of software – the human element.  Not having a path for obsoletion is a difficult thing to deal with.  The pressure of having to develop for an unknown set of limitations, along with having to support the current products is intense.  Then add the fact that this portion of the product is the center of integration for the hardware, the hardware-in-software, the application level software and the PC configuration software and small, human-like slip-ups tend to blow out of proportion very quickly.  And so as another reaction to this, any subsystem which functions ok, but not-quite-well-enough to meet the demands of the new functionality, tends to end up being re-written, rather than have the functionality of the client pared back.  Or at least making a balanced business decision based on the merits of both options.

So the intense pressure of almost constant inter-team integration, trying to provide their normal service functions to many different products (teams) as well as having every single mistake being jumped on by almost all of those teams, leads to an attitude which slowly poisons morale.  This is further exacerbated by a relatively large turnover of team members.  The end result is the conclusion that their code is more broken than anyone else’s, which it isn’t – they’re just as human as the rest of us, pervading a Broken Windows mindset.  So there is an almost pavlovian reaction to not want to do normal development and change, because it causes other teams pain.

This appears to me, to have resulted in a low team-esteem over the work they’re doing, as many of their mistakes are blown up to be much worse than they really are – even if they could have been caught as a result of stronger testing – and the best result when something is implemented correctly is that nobody notices that anything changed.

One of the main symptoms I have seen of a team in this situation, is that they joke about how awful or complex their code is, and that changing it is nigh on impossible.  This is not cut and dried, because my current team does this kind of joking too, but I guess it’s also coupled with the attitude that we can and are doing something about it.  We don’t feel shackled by time pressure or difficult-to-test legacy code.

So what, if there is any, is the generic learning to come from this?  Am I just having a rant about my old team?  No.  I get frustrated with what I see is the team attacking the wrong problem when they are desperately trying to keep up with the demands of the project, but that’s only because I know that they’re capable of some truly astounding things (there are some really smart guys in there) if only they’d get their priorities in order.  The generic learning, I believe (and as the title would suggest) is that writing software is a total mindset.  You can’t go into tackling a problem expecting to fail.  You must believe that everything will work out for the best, and test like anything to prove that that is indeed the case, before releasing it the world.  (Ideally, test before writing any code… but that’s a different story).  A team will not produce quality software if it isn’t happy about what it’s doing, and if it’s not happy about what it’s doing, it will more easily wander off and create solutions for problems to be defined at a later date.