Title: Professionalism in Programming #35

Author:

Date: 06 December 2005 05:00:00 +00:00 or Tue, 06 December 2005 05:00:00 +00:00

Summary:

In the last issue of C Vu we started a journey into the world of software development teamwork. We looked at team structure, personal skills for good teamwork, at team working tools, and team organisation. Phew! That's quite a lot of stuff to take in, but I guess after two months you've finally digested it all, and are now back ready for more.

Body:

Recovering from failure is often easier than building from success. (Michael Eisner)

If you're not, I'd quickly take an Alka-Seltzer and prepare for the next instalment…

This time we'll look at "team diseases". I don't think they're contagious, but handle with care just in case.

Team Diseases

You can have a good spread of programmer types, wonderful team organisation, and use the best tools to their maximum, but still have a dysfunctional team. There are many reasons that teams fail to produce results, and just as we stereotyped different species of programmer [Goodliffe] we can generalise categories of doomed development teams - to see what we can learn from them.

So here are some of the classic team disasters. In each case we'll see:

their particular road to ruin,
the warning signs (so the you can recognise when you're headed in this direction),
how to turn around a team stuck in that particular rut, and
how to be a successful programmer in that team situation (sometimes despite the team)^[1].

Hopefully you won't recognise your current team in the following list:

1. Tower of Babel

Just like the Biblical builders, a Babel-esque team suffers a massive communication breakdown. Once the programmers fail to communicate, development work is doomed - if anything works then it's more likely by luck than by design.

With ineffective communication people make incorrect assumptions. Bits of work fall between the cracks, potential error cases are ignored, faults get forgotten about, programmers duplicate effort, interfaces are misused, problems aren't addressed, and small slippages, unnoticed, grow into mammoth project delays because no one is monitoring progress.

Of course, the original Babel builders were fragmented by multiple spoken languages^[2]; without multilingual programmers you'll struggle to communicate in this situation. However, these kinds of project rarely suffer Babel syndrome - with language barriers to cross people make more of an effort.

It's not only different spoken languages that can separate developers. Different backgrounds, methodologies, programming languages, even different personalities cause team members to misunderstand one another. A small seed of confusion, unchecked, will eventually grow; resentment and frustration will build up. At worst, Babel teams end up not talking at all, with each programmer sitting in their own corner, doing their own thing.

This problem can brew within the immediate software team, and also between interacting teams. Extra-team Babel syndrome kicks in when developers fail to talk to testers, or the management team are disconnected from development.

Warning Signs

You can tell that your team is headed towards Babel when one developer can't be bothered to ask another about something, feeling it's not worth the effort. It creeps in with a lack of detailed specifications, and with ambiguous code contracts. You might see either too few, or too many emails flying about. Too many emails means that everybody's 'shouting', and no one's listening - nobody has time to keep up with the constant barrage of information.

On the road to Babel there are no team meetings, and no one person knows exactly what's going on in the project. Pick someone at random: they can't tell you whether development is on course or not.

Turn Arounds

Talk to people. Go on - open the floodgates! Soon they'll all be doing it.

Babel attitudes are difficult to redress once the rot has set in because morale has been dragged to an all time low, apathy is rampant, and no one believes that change is possible. The most effective strategy is to work at boosting team morale, to bring the developers closer together. Do something social to shake the team up: consider a team building exercise, even a simple trip out for a drink together. Buy some cakes one lunchtime, and share them with the team.

Then develop some strategies to force people to talk to one another. Create small focus groups to scope new features. Put two people in charge of a piece of design work. Introduce pair programming.

Success Strategies

To write good code in the face of such problems you have to be very disciplined. Before you start a work package ensure that it's rigorously defined. Write the specification yourself if you have to, and mail it to all the involved people to get their buy-in (provide a time limit for comments, stating that no feedback is assumed to be agreement). Then it's clear when you've succeeded because you have fulfilled the agreed spec.

Lock down all your external code interfaces fully, so there's no confusion about what you're relying on, or what people can expect of your code.

2. Dictatorship

This is the original one man show, a team led by a strong-willed, strong-personality, who is (usually) a highly skilled programmer. Other programmers are required to be 'yes men', even if they don't want to be, following the Dictator's mandates without question.

In some teams this works fine - with a well-chosen benevolent leader and a team who respect him. Problems loom when a Dictator's personality doesn't support his position, or when he is technically substandard. If his ego gets in the way then the team is in trouble: they will resent him, and grind to a frustrated halt.

When fashioned on purpose, this kind of team is a hierarchy, with lines of defined authority. This structure was likened to a surgical team by Frederick Brooks [Brooks]. The surgical team places the most highly-qualified technical individual, the lead surgeon^[3], at the top of the pile: acting as a code writer, not a manager. He performs the bulk of the development and has ultimate responsibility if bad things happen (if the patient dies). He is backed up by a deliberately chosen team. This includes a junior surgeon who performs smaller, lower risk tasks, supports the lead surgeon, and learns the trade. The team also involves the software equivalent of anaesthetists, nurses, and perhaps more junior surgeons learning skills (e.g. sewing the patient up).

There are two dangers with this kind of team. The first comes when external pressures force the Dictator to become more of a manager; his technical specialism pretty much guarantees his management will suck. His focus will shift away from the software and the project will collapse. The second danger is a self-appointed Dictator, who isn't recognised by the team. Work flow will stall as the team is neither structured nor prepared to support his leadership.

Warning signs

This team structure tends to develop slowly and subtly, as a would-be Dictator slowly modifies the focus of his work role and presumes his level of authority. You can see a Dictated team brewing when you often find yourself saying:

I can't do this without consulting ...
Oh, ... will moan if we do it like that.
But ... says we must do ... first.

Turn Arounds

If you have a Dictator who is not a worthy lead surgeon, then you must address the situation. Otherwise the team will petrify under this authoritarian tyrant. Either work the issues through with him (in all honesty, this is unlikely to work - change is hard, especially for people with an inflated ego), or unseat them from their throne by confronting a manager on the issue.

The problem with doing this is that after overthrowing the king, without a team restructure, you need a new king. Lead surgeons are hard to come by, and so it's probably better to restructure the team.

Success Strategies

In a (functional or dysfunctional) Dictatorship, determine your level of authority and responsibility. Get this agreed by the people whose opinion really counts - your manager or team leader.

However, once you've asserted your rightful development role, you (and the other programmers) must still listen to and work with the Dictator, even if you don't like his current position. Otherwise you won't work well together and won't write complementary code. There must be consensus in the design, or the software will not work.

Don't be disrespectful or rude about a Dictator - it'll bring the team morale down and make you more cross.

3. Development Democracy

An old proverb says: all men are created equal, and here this is outworked. This is a team of peers - programmers with similar levels of skill and complementary personalities - who organise themselves in a non-hierarchical fashion. It's an unusual beast in the corporate world, which expects that someone must be 'boss'. The idea of a self-organising team seems heretical. However, it has been shown to be a team model that can work well. Some Democratic teams run by periodically electing a leader from their ranks, based on whose skills are most in demand at this stage of the project. Often there is no a clear leader, and all decisions are taken by consensus.

We tend to forget the other half of that proverb: all men are created equal, but by practice grow apart. It takes a special set of individuals to make this team culture work. The danger with a team founded on this laudable principle is that as it grows, or when a certain member leaves (the one who crystallises the group into making decisions), things begin to drift. The team can lose it's focus, failing to agree on anything, and failing to produce results in a timely fashion. In the worst case, the team ends up arguing forever about a single issue, contemplating its navel, and never actually achieving anything.

With endless meetings and circular discussions the team is in danger of analysis paralysis: of becoming focused on process, not on delivery of the project. Like a real democracy, the genuine team business can get lost in a sea of politicking.

You can accidentally end up with a Development Democracy if you have a ineffective team leader who is incapable of making decisions. This kind of bumbling leader will slowly phase himself out without realising it. The frustrated team ends up jointly taking over his role - forcing decisions to be made and choosing the direction of development. Democracy is a particularly difficult team structure in a crisis, even when established on purpose. If personality friction prevents the election of the right man for the situation, then an outside leader must be brought in to steer the project.

Warning Signs

You can smell a sick Democracy a mile off: the rate of decision making drops like a stone. If there is a software team leader then everyone bypasses him, rather than be stalled by his dithering. He is now a leader in name only; no one recognises him as being an authority on the software or able to achieve anything.

Without strong leadership, no one is assigned responsibility for each task; it's never clear who should be ensuring a task's completion, and so nothing gets done. Weeks can go by without a specification being completed, and with no visible progress.

In a rampant Development Democracy the smallest decision forces the team into committee mode, and it takes days to conclude. Or a decision is made: let's say 'yes' until we decide to do something else. "Let your 'yes' be yes, and your 'no' be no"^[4], otherwise you'll spend ages ripping up old code and redoing it whenever someone changes their mind.

You might also notice that junior programmers feel alienated because they'll never be elected leader.

Turn Arounds

Democracies aim to remove a specific bottleneck: where all decisions must be made by the boss, who is not always the most appropriate person (especially when they're not technical). In a dysfunctional Democracy there is no decision making process, and no decisions are made at any level. To return to a healthy Democracy, ensure that leadership can move around the team freely and that replacing the leader is easy. Don't attempt to run a Democracy unless you have enough potential leaders.

As with any other slipping project, make sure that problems are visible to everybody, both developers and managers. Make sure that it's clear who's responsibility this problem is - especially if it's not yours!

You can attempt to correct indecisive Democracies by showing some strong will; don't be content to let matters continually slide. You'll probably get a name as a trouble maker, but eventually you'll also get a name as someone who achieves results. Beware, though, of the danger of becoming a demi-Dictator as a backlash.

Success Strategies

For your own sanity, avoid ditherers - the people who cannot decide the simplest thing.

Ensure that you are allotted a well-defined part of the project, and have clear and realistic deadlines. This is a major anchor against the ebb and flow of uncertain leadership.

4. Satellite Station

A Satellite team - split from the main development team - present their own world of potential pain and pitfalls. It's hard to work as a cohesive unit when part of the team is physically separated. Think about using a severed limb; it's not dissimilar.

The Satellite might be an entire peripheral department, or a part of your immediate software team split in a different location. Telecommuting (working from home) is a special case, with only one person in the Satellite.

It's not unusual for upper management to be in a 'head office' elsewhere, but since they have little input to the day-to-day programming activities this isn't problematic. However, if test or other development teams are many miles away then you need to put measures in place to ensure that the project succeeds. You must be deliberate about this - split teams don't work together by accident.

Programming requires close team interaction because our individual pieces of code must interact closely. Anything that threatens our human interactions threatens our code too. These are the kinds of threat presented by Satellite teams, so take them seriously:

Physically disjoint development teams lose those informal, spontaneous conversations that spring up beside the coffee machine. The chance for easy dynamic cooperation disappears. With it goes a level of shared insight and group understanding of the code
There is a lack of cohesion in development. Each site's local practices and development culture will differ (if only slightly). Inconsistent methodologies make handing over work complex.
Since you don't know people in the Satellite very well, there is an inevitable lack of trust and familiarity. A them and us attitude quickly emerges.
Another old proverb says: "out of sight, out of mind". When you don't see Satellite programmers regularly you'll forget to ask how they're progressing, and won't think whether your change impacts them (technically or procedurally).
Satellites make the simplest conversation difficult. You need greater awareness of other programmers' schedules; when they're in meetings or on holiday.
With cross-country projects, time zone changes become especially problematic. There is a smaller communication window between teams, and a larger eclipse period.

Warning Signs

Geographically split teams are obvious, but also be wary of separated teams within the same office. Splitting developers into different rooms, or even across corridors, imposes an artificial divide that can impede collaboration.

Watch for separation between departments, too. It can be just as damaging. For example, test teams are often hived off separately from the developers, sometimes in a different office or section of the building. This is a real shame; it hinders essential interaction between the teams and so the QA process is not as fluid as it could be.

Turn Arounds

A Satellite Station team is not necessarily doomed; it just requires careful monitoring and management. The problems are not insurmountable, but definitely inconvenient - avoid them if you can.

An essential survival strategy is to get all team members meeting face-to-face very early on in the project. This helps to build a rapport, trust and understanding. Regular meetings are even better. When the team assembles provide food and drinks; this sets people at ease and creates a more social atmosphere.

Arrange the Satellite so that their work requires the least collaboration and coordination with the mothership. This will minimise the impact of any problems.

Avoid code interaction problems by defining interfaces between the separate sites' work early on. But beware of designing your code around the team - you might not be creating the most appropriate design. Programming is a process of making pragmatic choices; each individual case is slightly different, and this is balance you have to weigh up each time.

Groupware becomes an essential tool in a Satellite, to make communication effective. Also consider using instant message communication between sites. And remember: don't be scared of the telephone!

Success Strategies

If you have to work with off-site people, make sure that you know them well - personally and professionally. It makes a big difference. You'll know how they react, and when they are being sincere or sarcastic. Make an effort to be friendly to Satellite programmers - it's easy to be mistaken for a grumpy idiot when they only ever phone you at inconvenient times.

Make sure that you know exactly who is off site. Learn everybody's name, find out what they do, and how to contact them. Work at improving your communications skills. Don't be afraid to contact someone when you need to - think whether you'd talk to them if they were sat beside you.

5. The Grand Canyon

This team is comprised of members with skill levels and experience at either end of the spectrum. There is a clear skills gap; the chasm between the 'senior' developers and the 'junior' developers has not been bridged, and so two distinct factions have grown. In almost every Grand Canyon team, this is both a social and technical phenomenon - the junior programmers socialise amongst themselves, and the senior programmers socialise amongst themselves. This isn't helped when the senior developers are seated together in one lump, and the junior developers in a separate ghetto.

The reason for Grand Canyon culture is often historical: a project starts with a small number of crack developers who must quickly establish an architecture and get proof-of-concept code out the door. They are naturally seated together and learn to work as a swift, cohesive unit. As the project progresses more programmers are required, and junior members are brought in. Because of the existing office layout they are seated on the periphery, and then given smaller programming tasks in order to learn the structure of the system.

Without careful checking, senior developers can adopt a superior attitude and look down on the junior developers. They hand over small, tedious chunks of work and continue with the interesting grander design work. The senior developers reason that it would take prohibitively long to teach a junior about the bigger picture, and there is an element of truth there. In this way, the junior developers never get a chance to gain more responsibility and do more 'fun' programming. They get frustrated and disillusioned.

Junior programmers want to learn their trade, and still have youthful enthusiasm and a passion for programming. Senior programmers may have a very different (more jaded?) world view, with aspirations for management or more senior development roles. These different personal motivations pull the factions in different directions.

Warning Signs

Watch your team if it is currently growing. Look carefully at the demographics of the members and watch how work is allotted amongst them. Monitor the social dynamics of your team - unhealthy teams develop cliques.

Turn Arounds

The problem in a Grand Canyon is that the team is not mixing; there are polarised factions. The fix is simple: adopt strategies that will mix them up. For example:

Change the seating plan, so that both factions are interspersed. This might consume valuable development time, but a day of desk moving might win weeks of productivity.
Introduce team meetings to spread information.
Start pair programming, mixing senior and junior programmers. Get the junior one to drive, whilst the senior navigates. This is a discipline for the senior, and educational for the junior.
Begin a mentoring scheme to train junior developers. Although this will emphasise the skills divide, it will also force the factions closer.
Look at all the developer's job titles - do they foster a dangerous and unnecessary pecking order?

Success Strategies

Treat everyone as an equal, as a peer.

If you're a senior programmer, recognise that the juniors need to learn. You were once a novice too, and didn't understand how the world worked. Don't hog all the interesting programming tasks. Be willing to let others take responsibility.
If you're a junior programmer, ask for more challenging tasks. Seek to learn. Perform your current task as well as you can - this will prove that you are ready for greater responsibility.

6. Quicksand

It takes just one person, one sour apple, one lose cannon, to bring a team to its knees. You need a brace of good programmers to make a good team, however you only need one bad programmer to make a bad one. A team stuck in Quicksand has unwittingly fallen foul of a rogue member. This can be subtle; they might not have even spotted where the problem stems, and the culprit probably has no intention of causing any harm.

You might suffer Quicksand for a number of reasons:

A technically incompetent programmer (probably the Cowboy coder [Goodliffe]). This guy isn't easy to spot immediately, and no one will notice whilst he's writing poor code. The timebomb has been laid, and later the project will be stalled until his mess has been purged and replaced.
A morale drain sits under a little black cloud and demoralises the entire team, sucking out all enthusiasm and cheer. Within a few weeks no one can bring themselves to write any code, and they're all considering jumping off the nearest bridge.
A mis-manager performs the exact opposite actions of a good manager, constantly changing decisions, altering priorities, shifting time-scales, and promising the impossible to customers. The team members don't know where they stand because the ground is always moving under their feet.
A time warp programmer bends the laws of relativity, so that time slows down around him. Anything coming his way takes a phenomenally long time to process. Decisions stall on his input, his coding work doesn't get done, and meetings always start late because he can't quite make the start. There's always a good reason - perhaps he is doing other 'very important' jobs - but he amasses a backlog of tasks and never gets round to anything. Eventually other programmers get fed up and bypass him.

In a Quicksand team one member's weakness can quickly destroy the entire team's productivity. This is especially dangerous when the culprit is high up the food chain. The more responsibility he has, the more dire the consequences.

Warning Signs

Look for the one guy who doesn't gel with the team. He's the person that everyone complains about^[5], or the programmer who always works alone (because everyone avoids him).

Turn Arounds

The most drastic but probably the easiest fix is to get rid of the Quicksand cause. First you have to identify him, and sometimes that's quite difficult.

Calls of unfair dismissal frighten managers, who will be reluctant to fire someone because 'a few people can't get on with him'. It takes some major league incompetence to make this a likely outcome.

So you've got to find a way to minimise the chaos he can cause, or work out ways to integrate him into the team better.

Success Strategies

Most importantly: don't be the Quicksand!

Presuming you're not, try to insulate yourself as much as possible from the effects of a Quicksand team member. Limit interaction with him, for the sake your blood pressure. Don't rely on his code too much, and try to avoid his input as much as possible. Don't get sucked into his bad practices, and don't over-react to him - acting the exact opposite and making matters worse.

7. Lemmings

Like a group of cute, furry animals with an insane urge to launch themselves off the nearest cliff, this team is far too willing - even eager - to accommodate the brief they've been given. Even when it's bogus.

The team comprises of very trusting, very loyal members. They are technically competent, but don't see beyond their specific instructions. Their enthusiasm and eagerness are commendable, but without a visionary member - someone who asks why?, who looks beyond the spec to what's really required - the team is in constant danger of delivering what was asked, but not what was needed.

Lemming teams are particularly vulnerable to the demands of start-up companies. The disease starts when managers ask: write this code quickly; we'll redo it properly later. Later never comes, instead the Lemmings hear: the company needs more code, fast, so just bolt this on quickly too. Before long the team culture is to dance when someone plays music. The work gets slowly more and more difficult, with ever-more herculean tasks and an ever-decaying codebase.

Eventually the team find themselves a broken mess at the bottom of a sixty foot cliff. Game over.

Warning Signs

If you're not happy with the specification you're currently working to then you may be in a team of Lemmings. You need a realistic faith in your current project, or you're a mere code mercenary. When you find yourself listening to vacuous promises and being committed to unreasonable work, and when no one argues or points out flaws in the plan, welcome to Lemming country. We hope you enjoy your stay.

Turn Arounds

Review what your team is doing right now. Don't stop working, but take a view from the customer requirements right through to final delivery. Will the code you're working on provide what's ultimately needed? Is it a short sighted hack that won't stand the strain of many years in your codebase, or many years of use?

Success Strategies

Question the work you are given. Understand the motivation for it. Stand up for good programming principles, and never believe that you'll be allowed to fix code later, unless you can see it scheduled on a plan that you believe in.

Next Time

Having thoroughly depressed ourselves at the sight of failing software development teams, we'll conclude this series by developing some principles for healthy collaborative software construction, and looking at the natural life cycle of a software team. Until then, enjoy the software factory…

With thanks to David Brookes, cartoonist extraordinaire, for the excellent monkey pictures.

References

[Goodliffe] Pete Goodliffe. 'Professionalism in programming #30 - #31: Code Monkeys' in C Vu 17.1 and 17.2, 2005.

[Brooks] Frederick P Brooks Jr. The Mythical Man Month. Anniversary Edition. Addison-Wesley, 1995.

^[1] I don't claim that these strategies will solve the team's general problem; they're deliberately short-sighted ways to get your work done now, with minimum risk of problems.

^[2] Genesis 11:1-9

^[3] Usually this guy is a technology specialist, as defined by Belbin's team roles.

^[4] Matt 5:37, unless you're a Babel builder, in which case your 'yes' might be Oui and your 'no' Nein!

^[5] They'll complain behind his back, which is a part of what drags the team into Quicksand. No one addresses the problem head on. No one likes to rock the boat. It will take more effort to confront him than anyone can be bothered to invest.

Notes:

More fields may be available via dynamicdata ..