What I’d like to spell out in this series are the ins and outs of taking over a project from another technical team. Spelling out the issues that tend to arise in this area needs to be viewed not only from a perspective of one development team taking over another’s work, but also from the perspective of commissioner-funders the project. How they might see their replacing an existing team.
There is a whole host of angles and fractal views from which to take up this topic. This then is the first of another series of articles – this series looks at Project Takeovers – and this opening article is a broad-brush attempt to sketch what are to be their chief themes.
Discussing projects part-finished that are handed over to you for completion puts me in mind of George Orwell talking about Hitler’s stormtroopers goose-stepping through Berlin and Nuremberg: “It would be laughable if it wasn’t so terrifying”.
Looking from the outside inwards there are plenty of belly-laughs to be had from this topic; and taking-over Projects might even make a good TV sitcom format; but sometimes even Hell looks inviting from a distance?
Reason number one is the lack of history you get along with the part-complete work. At best it’s a one-sided story, the commissioning client’s Authorised Version (no Apocrypha). Given that there has normally to have been a rupture followed by a total breakdown between client and former developer, this one sided story will always be pretty colourful, but in heavy shades of dark and light.
Another George Orwell item comes to mind, the Party Line dogma of ‘Four legs good; two legs bad’. In short- the other developer guy is always the villain of the piece. Sometimes even the client forgets that you yourself are a developer and he begins drawing generalities from his bad experience and starts unheedingly to tar your trade and all its practitioners with the same brush. Depending on how desperate you are for work, you might turn a deaf ear or else plead a fully-filled work schedule.
Of course, we are all human and so are all errant sinners, and so he might have a solid case against the former developer (developers are human too, in case you are not sure!). Nonetheless, to receive a doctored version of events is usual whether or not whose fault caused the break-up, and this is at best difficult for the new developer. Very few people can bear too much self-examination. (‘Humankind cannot bear very much reality’ T S Eliot)
The former developer will likely be ill-disposed towards the client, and so a very crucial source and route for obtaining valuable information to help you complete the task is sometimes cut off; although allowing for camaraderie amongst developers there might sometimes be some slack cut for you by him? Especially if he has a story to tell with grievances he might be just too pleased to get off his chest to ‘someone who understands’. So first points to note:
Approach the Former Developer to get:
- His side of the dispute; and
- Any technical background and advice he is happy to offer you.
- To get a bead on the client himself
- To assess in as far as you have opportunity the objective situation of the breach
- To find out whether the client is a decent payer (on time and without quibble?)
This final point e) is probably the most important item for you to find out. A person can put up with a lot of frustrations if the pay packet arrives in full and on time.
Regardless of the answers had from a former developer be prepared for a lot of deconstructional work on what has been achieved so far in the Project. Whether the client or developer has been the one who is inept or inexpert the net result is often the same: the software you inherit will almost certainly need unravelling, beginning again if not at square one then at a point far back before things began to fall apart administratively.
This is because at whatever entry point in a Project, and from whatever angle, comes into it a feed of chaos, in the shape of too many changed minds, overmangaging of minutiae, unscientific expectations, the quart in the pint pot (“feature creep” is the trade term), and so on: like a good leaven it will propagate through the whole batch and raise the loaves of consternation within it.
In all this there is another general rule arises, that:
The software build and the technical side of things will go far more smoothly and be a lot easier than the handling of the human aspects of Projects and of their interested parties. A psychiatrist friend of mine once quipped to me that ‘a neurosis shared is a neurosis squared’ – one might say much the same for the human relations management involved in taken-over projects. Unless one has a foreknowledge of experience in these things you might not be fully prepared for the upgraded bagatelle game involved.
There is likely to be enjoyed a ‘honeymoon period’ between you and the client but his bad experience that led to you getting the half-formed app or build to finish has made him more wary and skeptical about developers and their ways, and he will be more on guard than he had been previously and sometimes will be looking for ‘unconformities’. It is hard to say whether a non technical client is better or worse than a technical one.
Alexander Pope once said: ‘A little knowledge is a dangerous thing’ and perhaps half-knowledge is the very worst state for a client to be in. The client ignorant of technical things is the kind most likely not to accept being told by a techie he is asking for too much or the wrong sort of thing and so on. This is because he cannot appreciate the limitations of IT science. For a client who knows a lot about techie things one always asks ‘Why isn’t he building it himself?’. Sometimes this is naively asked at face-value; sometimes it is asked rhetorically with some sarcasm when he is the kind who is looking over your shoulder every moment of the day.
But the client with half-knowledge can be truly awful. He can insist it ‘can be done’ and that he ‘can tell you how’; that he knows the budget is sufficient. He of all kinds of clients is the one most liable to seek for mission-creep and to pile up add-ons and extras, and to suggest inarticulate tinkerings. You lose either way – do as he demands and the app is crap – do as you believe in and he refuses to sign off.
Considering these conflicts arising between Clients and Developers it is not surprising that so many projects are handed on to the next firm half complete; and it is surprising that so many projects see it through to completion.
To say a word in favour of clients, so that there is some balance to this article, it is true that developers often can be not the most forgiving of people, and can be abrasive, and from the perspective of clients, ‘difficult’ because they too have had a history and experience of tangled relations just as clients have had. They too feel they are ‘once-bitten’ and so they are now ‘twice shy’, and so they are very defensive right from the off. If developers were good at human relations they would not be developers; they would be in conflict management where the money is.
The scientific mind is one that is least liable to ‘suffer fools gladly’; because perhaps the precision of methodology into which it has been trained heightens its sensitivity to loose thinking and approximated accuracy. These however are the norm for more or less ‘ordinary’ kinds of people. Such a heightened sensitivity cannot bear these casual outlooks which it sees as being ‘slapdash’ and it finds them an enormous source of frustration and annoyance. Yet what is more necessary for handling people well than a certain ‘easygoingness’ and a broad ‘willingness to tolerate human foibles’?
The two outlooks are thus ‘chalk and cheese’; so is it any wonder that after the marital arts, the second place for exercise of mutual self defence goes to techie-client relationships? Like an old married couple.