Journal Articles
| Browse in : |
All
> Journals
> CVu
> 176
(12)
All > Journal Columns > Professionalism (40) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Professionalism in Programming #35
Author: Administrator
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)
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
T
his 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.
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.
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?
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.
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.
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).
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.
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.
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.
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.
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?
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.
[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 ..