I have just come in from a rather hostile meeting. Its purpose was to draw the lines between the role of a developer who has been working on a site for 6 years, and a consortium consisting of my company and a partner company, who are redeveloping the website in question. The rep who led the old developers was condescending from the start. She clearly felt threatened… our three against their two. Or maybe she’s just like that – hostile.
It’s incredible how I can sit through the first five minutes of a meeting without opening my mouth, being treated like I graduated from high school yesterday. Even more amazing is the fact that I quite often get treated like I don’t speak English. In 21st century Australia. In any case, she was rubbishing our solution from the start, unauthoritatively and with very under-developed arguments. To her credit, she did make it difficult for any of us to come back at her – you can’t really defend yourself against a tirade of crumbling poo cakes.
Her next mistake was to say that their company had had clients request to move away from the technology that we are proposing to use, in favour of theirs. Notwithstanding the fact that their solution is sh*t, the fact is that technology shifts happen all the time, for any number of reasons, technological superiority being only one of them. It stank of insecurity, and perhaps even desperation.
I can understand. The client has probably been a cornerstone client of theirs for a while, and they can’t afford to lose their patronage. This is a plight that affects many development companies in Australia, including my company back in its hey day. While I have pretty much broken free of a reliance on one or two clients, many developers do not. It’s always nice to stay within your comfort zone and work with people with whom you are familiar. However the implications of doing this are serious; more often than not, both parties – client and developer – will end the relationship in tears because their fates have been intertwined from the start.
The current situation is a case in point. I am not cheesed at the way the meeting with this woman went (ok maybe a little, but then you would’ve been too) – the theme I am getting at is the fact that she was so reluctant to cooperate; this is behaviour I find extraordinary in any reputable web development company. Wresting control of the public website in this instance was easy… the client was fairly adamant that my partners should just take over. When it was even suggested that the back-end be handed over as well, we were met with a simple “it’s too complicated”.
Never have I come across such a poor reflection of competence – an outright admission of failure to keep a good audit trail. I wager that you would only need to look at their code to see why – I have seen so many solutions arrive on my desk with documentation and annotation scoring a perfect 0, and this solution would probably be one of them.
It’s one of two things, really, and to accuse them of one (incompetence) would be unfair. It could also be that they are acting strategically, locking the client into a relationship such as the one I mentioned above – the intertwined fates. They could hand over all of the source code for the project and it could be as useful as a Brisbane UBD map in Melbourne.
I was accused at one stage of claiming that the client, who was sitting to my right, had failed to do his due diligence before embarking on his relationship with these clowns. I didn’t object, and mumbled “I just find it extraordinary, that’s all”… that the product has been left in such a state of mismanagement. If the fit eventually hit the shan and the client sued the old developers for a piece of crap software, the developers could probably enter a defence claiming lack of due dilligence on the client’s part and get away with it, but I feel the client couldn’t know any better. It’s not like you can find out about true incompetence by any means available to normal due diligence testing.
It is my opinion that this client has either been duped or the developers have not provisioned for record keeping in their time estimates. A word of caution to anyone out there looking for application developers: developers come and go. Your website will belong to you, regardless of who builds and administers it, and it’s therefore up to you to ensure that it is a well-managed piece of intellectual property. If your developer cannot prove that it’s been written in a way that is compatible with your mutual exit strategy, then run!
What should you be looking for?
- Internal annotation within the code that explains the logic of code blocks, dated and attributed to a developer.
- Chronological logging which reflects who did what and when.
- Document libraries containing all associated documents (such as third-party specifications, project briefs, design briefs… with all major and minor versions present).
- UI documentation – the documents that explain the user interface to the client, and all levels of end-user.
Ultimately, you should trust your developers, but trust them as business partners. Because when you cease to do business with them, for whatever reason, they should be able to bump into you in the street months down the line and comfortably ask how their former project is doing without any ill-feeling on your part or theirs.
Growing up, I had the privilege of living in a household where most of the domestic work was done by a maid. Returning home recently, I met for the first time Sophani, a sweet and caring Cambodian woman who helps my parents with the cooking and cleaning. As it turns out she speaks hardly any English but she tries, and for that I have the deepest admiration. One day while watching someone attempt to deliver instructions in English, I was reminded of one of the oldest stories about Sun Tzu…
Sun Tzu had this to say about planning…