It’s the kind of project that you could do in your sleep. You’ve done a hundred of these before, so after examining the prospect’s existing configuration, you gave them a ballpark estimate with just a little padding so you’d feel absolutely safe.
You know what’s coming, don’t you?
A week into the project, you discover a section of existing code that will have to be massively reworked in order to bend it to the requirements of the project. It will be eight or nine hours of extra work, but it’s no big deal because you padded your estimate exactly for unforeseen gotchas like this one. From the sparse comments and version logs, you realize that the idiot responsible for this obstinately brittle design was another consultant. The client has mentioned their previous consultant’s name in passing, but they’ve never elaborated on the quality of his work or the circumstances of his departure.
“Well, at least it’s only in one place,” you think to yourself — then immediately decide to make sure that’s the case. You check out module after module, only to find the same design (using the term loosely) philosophy (thinking Absurdism here) applied to every single one of them.
What will you tell your client? Will you revise your estimate, or just try to knuckle down and get it done? Will you tell the client why this project will take longer than you thought?
In extreme cases like this one, I think we’d all explain to the client how a more-sub-standard-than-expected existing implementation blindsided us. But what if it was a flaw that didn’t really impact your schedule? Would you still let the client know that their previous consultant did a shoddy job?
You could argue that your client has a right to know all significant details about the quality of their code. Perhaps, too, shedding some light on the quality of a past consultant’s work could help them in choosing consultants in the future. If that consultant left on bad terms, this knowledge might help your client feel better about not having them around any more.
You have to be careful, however, when criticism of other consultants is coming from your mouth. Your client could misconstrue this as you trying to make yourself look good at your predecessor’s expense, or justifying a schedule overrun, or churning up additional business fixing something that ain’t broke. You are not and cannot be a purely objective observer, so it’s good to recognize your interest and deal modestly with the facts. After all, it’s not like you’ve never made a mistake. Would you be comfortable if we went back and critiqued that system you designed 10 years ago — the one that still makes you grimace whenever you think about it?
Remember, in every conversation with your client you want to communicate that:
- You will always be honest.
- They can trust you with their most sensitive systems, data, strategy, and relationships.
- You care first and foremost about solving their problems.
- You either know how to solve their problems, or you can find out how to do so, even if that involves referring them to someone else.
So, in our example above, I’d approach my client and explain that “This will take me longer than we had discussed. In my initial examination of the system, I missed some design decisions in the existing code that conflict directly with what we need to accomplish. I didn’t anticipate the approach adopted by earlier developers, because I would not have designed it that way myself. I’m sure they had their reasons for choosing that direction, but so far those reasons have eluded me.”
Even though what you’d like to say is “What idiot with even half a handful of moldy cottage cheese for brains would ever create a pile of stinking filth like this and call it an application?! The true feat of engineering here is that this code monster didn’t swallow your whole organization in the black hole of its utter lameness. Where did this person learn programming — NBC?”