Project Management

Do you ever bad-mouth clients' previous consultants?

When you discover shoddy work by another IT consultant, do you tell your client? If so, what do you usually say in this situation?

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?"

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

33 comments
herlizness
herlizness

There are those times when the truth about previous work simply must be told or you risk owning it yourself. One dimension of doing so that I've seen overlooked is that a sharp critique of a predecessor's work can be construed as implicit criticism of the client for hiring that person or entity or not monitoring the quality of their work. It goes without saying that you don't want your client to feel stupid for their prior decisions.

JamesRL
JamesRL

My university experience was an arts degree, with one Fortran Programming half course. I managed to land a summer job at a polling firm, and had lots of exposure there to mainframes. A few years later I got a job as a dba of a custom db for sales/marketing at a software company. Pretty simple stuff, data entry, creating merge lists on selects, running the backups etc. Entry level, but I wasn't a programmer. This was a forerunner CRM type system, the sales people would track their calls in the db, I would track what marketing material had been sent etc. Everything was pretty good until someone in marketing bought a list of prospects. It would double our database. I didn't think anything of it. Until the database stopped working. Fine, the original coder of the database had been a summer student before I had joined the company. So I went to the in house programmers and asked for some help. So sorry, they told me, too busy debugging the upcoming release that they were already late for. "What can I do?" I asked. "Do it yourself" was the reply. Easier said than done. I had studied Fortran 4 years earlier. This required COBOL. The company's product was a COBOL development environment, and I had taken a weeks training on it. "So give it a try" they said. Until I fixed the problem, no one had access to the data, so I rolled up my sleeves. I discovered, for whatever reason, the original programmer had put in a fixed limit, hard coded a maximum number of records. Why, I asked myself, we had lots of hardware, really no reason for such a constraint. I did manage to find it and fix it in under a day, but I'd been under serious pressure all that day. So I am afraid that young naive me did bash the guy. None of the in house team could figure out why he did it either so I guess I kinda lead the charge. Six months later comes the office Christmas party and I see a few faces that aren't familiar. One of the programmers, who was also a good friend, slid up to me and pointed out that student programmer. We had a good natured mock outrage charge that was just for a few of us to understand. I know better now. Unless you are a new maangement hire and you wanna bash the company's corporate consultants, thats fair game. :)

Oz_Media
Oz_Media

If you slam a previous consultant's work, you may as well just tie up to the closest rack and hang yourself. First off, you could be bad mouthing the bosses family member, secondly it could be old code, you have no idea whether the last consultant was even paid or allowed to use the tools needed to do it properly. Lastly, slamming the last guy is the weakest customer skill of all, an absolute no no on ANY account. Talk about YOUR work instead, talk about what YOU did, not the last guy. This often raises questions; Q) "I thought the guy we hired last month had taken care of that?!" A) I believe he did but it seems there was some code that was perhaps missed or he didn't notice some of the issues, not to worry, I've done it now (or I'll take care of it for you). I see this lack of ability/misrepresentation in sales reps all the time too. It would be too easy to simply say, he was clueless but instead I find it far more effective to simply offer the right solutions and point out some drawbacks of an alternate solution, not mentioning someone else at all, just planting seeds that the employer will quickly work out himself and apply his own blame to the respective person. In Automotive it is exactly the same and I see shops do it all the time. "The last mechanic didn't know what he was doing, he did this wrong, THAT should have been done like this and that's why it died again." "I prefer, well there are a few things I've noticed, THIS should be here and if you change THIS, it will sort it out for you." The customer knows who he hired last and what he paid for it. They'll figure it out soon enough. Telling them their last hire did it wrong, is no different than laughing at them for their choice in technician. It belittles the customer's knowledge just as much as the person who last worked on it. BAD FORM, BAD FORM!

aharper
aharper

In our community we have three IT providers. While we specialize in on site service, another specializes in "in shop" service. We have had a mutually beneficial relationship for years and even entertained the concept of merging from time to time. really quite the idyllic life for small town IT. Along comes a prominent community members son, fresh from a large telecom/IT provider in the big city and sets up shop. His entire marketing campaign is based upon "me big city, them country bumpkins" approach, ignoring the fact that both of his competitors are retired from Fortune 500 IT, with Gov't, HIPAA, and SOX experience. Each of us have over 20 years of experience, and our shops combined have nearly 80 years. Because of his family connections, he got all the "good contracts". City, and county government, library administration, and many businesses went to so-and-so's son. We didn't even have time to feel the hit in the pocketbook before the disgruntled clients began to roll in. We joked that he was better than a yellow page ad, because it cost much more to fix his issues than it would have to simply maintain. Every job we re-did was a testament to how NOT to do a job. At first, we simply fixed things and billed, but later we began to document the issues. This documentation has been critical in helping the clients understand the issues at hand. One particular one comes to mind. A client who ran an antique store was convinced to purchase a non-dedicated server and a color laser printer, all new and under his Dell reseller account. When she got the equipment, he could not connect her to the internet on DSL. Not kidding folks! he couldn't run a wire from the phone box to the computer and make DSL work. When I went to fix it, I discovered 200 feet of some of the worst Cat-5 cable I have ever seen, spliced 3 times to span 38 feet above a suspended ceiling. I took pictures and explained the issue to the client, trying to be as kind as possible. A week later she called me about the printer. It said she was out of toner. I knew this was not possible, since we had just set it up for her. Sure enough, she was out of blue and black, and yellow was at 50%. Page count put it at over 62000 pages. Note that this was sold weeks before as a new printer, and the gentleman's logo was teal. The client did not want to pursue this, and simply bought new cartridges. Even though the man demonstratively is a blithering idiot, I NEVER directly bad-mouth the guy to the client, often taking great pains to do so. While the customers appreciate my candour and sensitivity, sometimes I wonder it it really is worth it. Right now, the city is in IT hell. They offered us the contract after they fired the guy, but on inspection of the network, we turned the job down. Now there is some legal question as to who exactly owns the servers. He wants some data which was stored on his servers in the city facility, and much is in limbo. Perhaps I could have simply destroyed him early on and saved everyone a ton of trouble, but I let tact and ethics get in the way. I wonder if I had been less kind, where would everyone be? Bottom line: You have to evaluate your measured response by the whole picture.

ps2goat
ps2goat

I refused to work on one particular project because the existing security was non-existent. Not only did they store the security code from the credit card, but they stored the credit card number unencrypted, and showed all the credit card info when a user viewed his profile. The owner gave me his account (you had to have one to view the products: B2B), and when I logged into it I had all of his credit card info! Looking in the Access database, I found out that everything was unencrypted. I told him he should address this prior to changing anything on the SEO side.

Englebert
Englebert

Experienced IT Managers know that there is always a tendency for the next programmer to criticize the work of the previous programmer. In hindsight, there is always a better way of doing things; besides you don't know under what circumstances the previous programmer was working under. Having said that, there are some notorious programmers who rush their work and make it a pain for others to maintain. I point the finger at the PL/PM who allowed this to happen. Now, what's worse than bad programming is bad design. Bad code, you can always recover (much as you hate fixing others sloppy work). Bad design you cannot easily, without having to run huge risks in order to set straight the system.

sann_mcghee
sann_mcghee

I don't ever bad-mouth previous consultants, but if there was something implemented that is not in the best interest of the customer, like hindering their ability to upgrade to the next release, I let the customer know. It is their right to know. Also, I would hate for another consultant to come behind me and think that the bad decisions were mine :o)

reisen55
reisen55

We had one client, a museum, where the previous consultant totally screwed up their backups to the point where it was non-recoverable from any number of perspectives, inclusive of tape capacity being way toooo small. These kinds of errors are great for new business but - without blame - we pointed it out the client in order to set the expectations correctly and verify that WE knew what we were doing. Do not blame - that is already implicit. You don't have to do that. Just point the out the error and apply the smarter fix. No blame required.

Nico Baggus
Nico Baggus

If it might impact Mission Critical code i will more actively persue the issue than if the impact is barely existing. A remark should be in the documentation of the project at hand. Also asking why something is done in a certain way can help, not blaming anybody, just "genuine" interest. But documenting the answers anyway.

chris.green
chris.green

Generally I think its poor form to do this unless someone has been stupendously bad, trouble is it can easily backfire as while the previous person may have been useless they could be a personal friend of the company or senior staff....

NickNielsen
NickNielsen

I was given dBase II, and tasked to provide a DBMS to track the distribution of interactive training packages. Since I had no training on database design, and dBase II was not capable of even pseudo-relational databasing, I spent several months working on it. The result was a masterpiece of recursive search and sequential variables. The runtime compiled to a whopping (for those days) 219k. It was, according to our resident C/Pascal developer (and section leader), highly innovative, if overly complex, coding. He proceeded, over the next years, to teach me about database and program design. My final major project, three years later, was to convert my original kluge to a fully relational system using Foxbase Pro. It took me less than three weeks. I spent the first two weeks designing the table and key structure, and the last week replacing the recursive search routines with table select statements, implementing arrays where required, and in general cleaning up the code. The final compile size was 87kB. I changed assignments a month later and have never coded professionally since. I don't miss it. I enjoyed the challenge, but don't have the patience any more.

Sterling chip Camden
Sterling chip Camden

... not based on a specific experience of mine. But the circumstances are a composite of various similar experiences. For my own design closet skeleton, I'd have to go back about 13 years instead of 10. But I really don't want to talk about that one <<shudder>>.

biancaluna
biancaluna

Uncanny, I have just commenced a consultancy in an organisation where one of the big 3 outsourcers messed up a project to the point where there is an unworkable situation in the workstation environment. There was a signficant role for the client as they do believe one can segment IT areas to the point where due dilligence and testing are dirty words. I try to keep my constructive criticism close to self - in my experience bla bla bla, here is what I've done for other clients, typically bla bla bla. Unfortunately, there are remnants of the old project team who express an amount of aggression at a mere whiff of any criticism so I need to be really careful. In a roundabout way you are exposing a level of incompetence and that means sometimes you get shot as the messenger. Never bad mouth, stay side by side with the client, and sometimes with the previous consultant as there are situations where the previous person is still there. This is probably more norm than exception, and can cause a lot of stress and angst, both in the client and for you, as the consultant.

Sterling chip Camden
Sterling chip Camden

You're right. Unless he agreed to remedy that situation immediately, you don't want to get tangled up in that legal mess.

Sterling chip Camden
Sterling chip Camden

What I mean by "bad code" is bad design on a small scale --- "bad design" simply means to me that the disease is far more widespread. Can you draw a qualitative distinction?

Sterling chip Camden
Sterling chip Camden

I've had that happen before, by putting my name on corrections to bad code. Suddenly, the whole thing is "mine".

Sterling chip Camden
Sterling chip Camden

I agree, and the more concrete your remarks the better. As soon as you start to generalize, it looks like you're trying to take it somewhere.

Sterling chip Camden
Sterling chip Camden

Using the Socratic method: "there's something here I don't understand -- could you enlighten me?"

Oz_Media
Oz_Media

if I read the posts through and knew you'd said it already I wouldn't have bothered myself.

njoy_d_ride
njoy_d_ride

Yessir, Ya have to watch out for this one... Much wiser / more diplomatic / classier etc; to play "love the coder, hate the code" and explain the problems without making referrence to the coder. Remember too that if the code doesn't seem to be following the guidelines of the project, those guidelines may have changed. Lastly, one of my pet peeves is working with an egocentric coder who thinks he's god's gift to coding and starts out badmouthing the code and coders who produced it before he's even looked at it. I've worked with several of these yo-yos, and the end result isn't pretty. The good coders I've worked with are too busy producing good code to badmouth.

Sterling chip Camden
Sterling chip Camden

... or it could have been the person you're reporting to, not well-identified in the artifacts.

Sterling chip Camden
Sterling chip Camden

... was DBASE and FoxPro, then you haven't really coded yet. I don't have patience for either of those "languages" myself.

boosterveen
boosterveen

it has been more than 10 years ago. I got a project from another programmer assigned to me. It was a scheduling program in Excel, written in VBA. The problem was that it took more than an hour to schedule 5 people, let alone more than 5. Besides questioning the wisdom of creating a scheduling program in Excel, I also found that the programmer was someone without a background in programming (oneweek course it seemed). The problem was that I could make the program better but the platform was no good (VBA in Excel, pleaSE) I started complaining but in the end I was forced to clean-up the code. Though it got more than 4 times as fast, still no good. I delivered the program and as far as I know, it was never used.

HAL 9000
HAL 9000

That you have no way of knowing what constraints where placed on the previous guy and when he walked away in disgust the company changed it's tune and wanted the thing to work which they found to be more important than their previous beliefs. I remember a Government Department who hijacked a M$ sales pitch for XP where M$ claimed you didn't need servers. So this Department proceeded to setup a 2500 Workstation Environment without a server in sight. Didn't matter that it wouldn't work or that those IT Staff told them so they wanted it this way without understanding that Release in the way it was intended and just took a few words out of Context. Being the guy in to fix that mess after the Governments IT Section Refused to have anything to do with this department was interesting to say the least. Also being reported to M$ Legal three times for supplying them Pirate Software has been interesting. Doesn't matter that the Government Buys the Licenses Direct from M$ I was the guy who was the IT Guy so I was responsible every time something went wrong. Didn't matter that it was the Bureaucrats causing the problems themselves and the IT people where just trying to do as instructed we where responsible and [b]Wrong.[/b] After all it wasn't possible or conceivable that they had done something wrong was it? :^0 Col

Englebert
Englebert

Bad Code is isolated to a program or a unit. Bad Design is a level or more higher, to a sub-system or system; as befits the System Designer who is a level or more senior to the Programmer. A Programmer may be given some leeway to code, but a Designer, IMO should always have his design work critiqued by other seniors. There's alway a better way of doing things. The funny thing is that the most hare-brained designs are done by the so-called smartest techies, yet the best designs are done by the most experienced ones

sann_mcghee
sann_mcghee

Now, I make the issue know BEFORE I correct it :o)

Sterling chip Camden
Sterling chip Camden

"The good coders ... are too busy producing good code to badmouth." quotable.

NickNielsen
NickNielsen

and used it for several years early in my AF career. It's what allowed me to pick up DBMS coding as quickly as I did. We had a developer on staff, but anybody who could tell the difference between DO WHILE and DO UNTIL got drafted to help out. My primary job was always maintenance. I just had a few assignments where I was not performing actual maintenance, but performing analysis of maintenance and training data.

njoy_d_ride
njoy_d_ride

dBASEII and FoxBase Pro are circa late 1980's / early 1990's. Ya think things have moved a little since then?

tclguru
tclguru

At a recent job, I had to enhance some code that was incredibly convoluted and entangled... it was a prime example of "code monkey" programming in that they used lots of advanced C++ features and yet the code was full of basic architectural blunders, like the same class (even the same function) doing everything from GUI processing to database updates. I could have griped and vented about it, but the horse was out of the stable and I had to knuckle down and work within the existing framework. Oh well, that's why they pay us the big bucks! :-)

Sterling chip Camden
Sterling chip Camden

VBA was what all the cool kids were using. Of course it had to work! Trouble was, it didn't.