Fog Creek Software
Discussion Board


My company seems to be moving towards the 'we hire consultants to design & build the system - then you will do the maintenance of it' philosophy.

I've had very bad experiences with companies doing things this way. (Our team had to re-write all of the consultants crappy code - most of it looked like it was just thrown together with no design to it). What is the point in hiring these so called 'experts' when your team can do it better & correctly the first time?

Wondering how you all felt about such a philosophy?

Friday, April 18, 2003


I'm on the other side of this situation, I work for a consulting firm and my opinion is that as long as you maintain a good relationship with these consultants, keep up with what they're doing (weekly status updates, etc) everything should be fine.  I'm not sure how big your company is or your relationship with the decision makers, but you could probably interview the developer/consultants and that way you could raise a red flag to your managers right from the get-go if you think he/she/they are incompetant.

Most of the projects I've done for clients who had developers in-house were good experiences.  However, there was at least one client who's developer was hell-bent on delaying the project, making me look bad, etc because they were worried we were going to take their job over.  In the end, it made everyone look bad (it was an enhancement to an existing app written by the in-house developer.)

>What is the point in hiring these so called 'experts' when your team can do it better & correctly the first time?

Just because you're a consultant does not make you an expert.  On the flip-side, if you're team can do it better, then why don't you?  Because you're busy working on other stuff more than likely.  They don't want to hire another N developers, hence consultants get the work. 

I don't like the term consultants - I think it's just a code-word for contract-programmers so that the in-house developers won't get pissed b/c these guys make $60/hr (or more.)

Normally Not Anonymous
Friday, April 18, 2003

Y'know, the term "consultant" and "contractor" are both misused. Again, there is always a political intent behind the words used in IT. Someone usually feels they have to label someone with a certain tag.

I've seen some of the most heads-down, mediocre code drudges claim they're "consultants" but they have to be spoon fed in a manner that makes some entry level people look like mensches.

On the opposite end of the axis, most/all of my clients would go out of their way to label me "a software contractor" so as to minimize the impact I've had on their operations. Yet, I have the following track record: generally I pull an unformed idea out of the muck and breath life into it; mentor entire companies on aspects of programming; come up with actual workable solutions and implement them while the FTEs and managers around me are wasting time nattering about bullshit and not articulating real approaches.

I've always worked as a hired gun expert, to get things off the ground that the locals and the natives simply had no clue how to do, using highly creative approaches drawn from a diversity of experience. But managers and clients will sneer "contractor, only contractor".

Admitted: most so called consultants are "drop and run"; at best, most love to do the imaginative and creative part of a project, then drop it like a hot potato when the smack is coming down. But this applies not only to individuals but to entire so called "solution provider" companies.

Basically, it's all just words. Some people are jealous & resentful of consultants, wanting schadenfreude. Others are dependent upon consultants but want that fact denied at all cost and do so using different words.

Bored Bystander
Friday, April 18, 2003

Oh, yeah, maybe I better answer the original question and justify my own high self opinion. :-)

I think that an appropriate use of 'consultants' (aka experts) is to bring new and needed skills and approaches into an organization. That *might* include implementation of systems that no FTE has the ability to "get going."

On that aspect - the client organization that has no or few internal new-project abilities - the consultant may be used as a short term crutch so that the management doesn't have to sustain the mistakes that will result from internal, perhaps lesser skilled and less diverse people taking a whack at new projects.

A misuse of consultants is to rely upon them totally while the locals stagnate with legacy and maintenance skills. *Nothing* is really unlearnable, and one bit of 'consultant ego' I am tired of is the consultant who considers it beneath them to train their successors.  One core skill of a so called consultant ought to be the willingness and ability to migrate enough knowledge into the client organization so as to make the client self sufficient in the future.

And some clients are (from the top down) in denial that their people need external help.

Bored Bystander
Friday, April 18, 2003

I didn't pick the moniker "Spaghetti Rustler" by accident.

Currently, I'm working on a product thrown together by a team of highly-paid retarded monkeys.  Calling it a "Big Ball of Mud" ( ) would be a compliment.  It is a complete nightmare, and looks like code that has been patched for years, not brand-new code.  No design methodology at all was used, as far as I can tell - they just sat down and started coding.  No UML, no CRC cards, no nothing, not even napkin diagrams - and this is a *huge* program.

And their knowledge of the language they were using was pitiful.  I'd like to blame it on them being kids just out of college, but they were all suppossedly experienced professionals.  Just goes to show you what a sad state our industry is in.

The good news is, I'm a consultant, so I get to make the big bucks (snort!) fixing this mess.  And frankly, I find I learn much more fixing other people's code than writing my own new code.  Anyone can write new code; it takes true talent to decipher "spaghetti objects"!

Spaghetti Rustler
Friday, April 18, 2003

Spaghetti rustler, expect your expertise to be minimized by the natives once you're done. But that's why we punish the client with sky high rates. We KNOW that someone who "can't do" will take credit. :-)

Bored Bystander
Friday, April 18, 2003

Spaghetti (or anyone really),

I am in a similar situation at my current job, but am full time.  The code base is a mess, and most of the "experienced" developers just keep adding to this mess.  I have suggested looking into rearchitecting small portions of this, but have met with much resistance.

Could you give me some pointers as to how to get the ball rolling with cleaning up the code?  Or were you brought in specifically to do that so it is not really a problem for you?

In addition, how do you teach the "experienced" developers to design and code properly?

Sisyphus comes to mind here...

Some Developer
Friday, April 18, 2003

Teach by living the example.  Refactor one small thing whenever you get a reasonable opportunity (hopefully you have an editor or IDE that will help with this).  Make each change impact only a few files.  (Sometimes, this means keeping two "versions" of a class or method around -- the old, crufty one which is used by most of the code, and the new elegant one which is used by your new code or other code you refactor.)


Friday, April 18, 2003

There are consultants who consult by giving their opinion and knowledge backed up by documentation and good code. They cost alot and are extremely rare.

There are contractors who do the same but are really hired guns to do the job...not think/analyze. This is because a company's management is given a budget and just wants the project done. Some contractors know what they produce is sub par and the hiring company's manager knows it too but there are politics involved.

Then there are the business types that give the warm and fuzzies. To a technically literate person these types are the worst of the bunch, but to a manager, sales guy, or a business analyst they are the best. These business type consultants produce crap but sound real good doing it.

Tom Vu
Friday, April 18, 2003

Open question prompted by Tom Vu's post: is anyone who can deal with business issues automatically lightweight, a poseur, not "hard core"? Do you have to be well away from the arena of perceptions, politics, presentations, suits, etc in order to be technically competent?

Does business knowledge mean you're a wanker, lightweight, ignorantly bullshitting everyone with a happy face meant only to get signatures on contracts without a care in the world how the miserably tough stuff is to really get done?

I'm *not* being sarcastic. Our industry seems to suffer from the stereotyped behavior and roles of two polar opposite personalities: people who can deal with other people successfully but who are all talk, who over-promise, and so forth. And those people who are technically knowledgeable but whom are treated as idiot savants who have their heads ignorantly, stupidly and self indulgently buried in code.

Bored Bystander
Friday, April 18, 2003

What's everyone opinion on your first software dev job out of school being at a consulting shop? 

Friday, April 18, 2003

Bored Bystander:
Anyone who can deal with business issues and is technically competent is my definition of a "consultant". They are rare and expensive. I think most companies would rather have the warm and fuzzies and a failed project than the truth. Case in point is the CAMEL thread by someone on this forum. 

Tom Vu
Friday, April 18, 2003

I agree with Tom, and explain it this way to clients:  "If you cannot tell the difference between a contractor and a consultant, you have contractors."

A consultant is a contractor who brings added value.  If you are bringing in a warm body, sometimes a necessity, you probably use contractors.  They are less expensive.

The original poster asked if his experience is typical.  I see much more of it in the past couple of years.  The intent is to hopefully "buy experience."  It is great if you can do it as it reduces project cost dramatically. 

Where I have seen it fail:
- New technology forced into legacy structure.  People do not know how to alter the SLC to account for the interactive possibilities. 
- New technology that pass by legacy structure.  This is when the new guys all explain that they can load straight to production and save a lot of time. 
- Inbreeding.  This is when a company supplies the expertise and does its best to ensure little knowledge transfer. Guaranteed support contract.
- Poisoning: Employees do their best to ensure the project has as little support as possible.  The attitude "why should I train this guy to eliminate my position."

Here is what I suggest for clients:
- Make it corporate policy that no consultant/contractor can remain in-house for more than six months after a project.  It hurts at first but is better long term.
- Contractually obligate knowledge transfer. 
- Recognize the added value given to employees during the knowledge transfer. (Example: We train 15 COBOL veteran employees to do SAP work.  Six months after we leave they have too, because the company failed to compensate them for their new value.)
- In a downturn always get rid of contractors/consultants first.  If they are critical to an ongoing project they stay, but keeping a contractor for a support role while eliminating an employee breeds problems. 
- Never recall a contractor/consultant if they are anything but outstanding.
- If you like a consultant or contractor, feel free to offer them a job.  You may need to deal with the source but the average recruiting cost for an employee is something like $35,000 and then you really find out what you get.

Mike Gamerland
Friday, April 18, 2003

I am a warm body in a consulting firm and I can tell you that our code follow Sturgeon's Law, i.e. 90% of it is crap.

Many of us do feel bad about it, but we have incredibly short schedules and know that delivering barely passable code in time yields a much better evaluation than asking for more time to create a good, maintainable system.

This obviously damages the firms credibility in the long run, but hey, in the long run we'll all be downsized.

An analyst that shall remain nameless
Friday, April 18, 2003

If you are working with experienced, good consultants why hire permanent staff?  When all is said and done, taking into account benefits/line management/training, et al, a permanent employee is not a great deal cheaper than a consultant.

Then consider that if you hit a downturn, getting smaller doesn't create as much pain.

Friday, April 18, 2003

Yes, the work of big - and sometimes medium - consulting firms is often mediocre or worse.

The reasons lie in the fact that those firms are by definition good at attracting and holding business, often using dedicated, aggressive sales teams. Those qualities are not related to doing good work, taking pride in work or even understanding the issues well.

This is actually the source of much of the angst that's discussed here. The imperatives to maximise revenue mean developers are pushed with irresponsible deadlines, troublesome developers are kicked out, and often pliant younger graduates are favoured.

One such big firm makes a "benefit" out of the inexperience of its staff: it crows that they can learn any new language in a week. Sure guys.

Must be a manager
Saturday, April 19, 2003

I've been a 'consultant' for 14 years, sometimes I find permanent employees types who are bitter and twisted about the fact that I earn twice what they do, invariably I find that they disappear when the going gets tough, have a weaker work ethic, have a short achievement list, lots of attitude (about external developers), are clock watchers, constantly looking for opportunities to bring you down a peg or two, are highly critical of your ideas (but have none of their own), and often contribute very little to the hard design issues (sure they can grunt a bit of code out) but will moan the loudest if something goes wrong, and if nothing does (as is usually the case) they think they should get a week of work as a bonus for delivering a system.

Generally a good consultant is worth about 5 average employees. That's why companies push permanent employees to the side when something meaningful needs to be done.

Saturday, April 19, 2003

>>Generally a good consultant is worth about 5 average employees. That's why companies push permanent employees to the side when something meaningful needs to be done.

I contracted on a huge ERP project where everything was done by contractors. The permanent employees got a new title "functional expert" AKA testers.

Tom Vu
Saturday, April 19, 2003

I prefer to refer to myself as a 'freelance programmer'. Do I do other things that provide value? Yes, but the vast majority of everything I do relates to the automation of some process/task. In virtually all cases, that automation requires that I write new programs, script existing ones, modify existing source code, connect to a database, etc. In some cases, it's a matter of showing someone how to use the built-in functionality of off-the-shelf software or recommending existing software.

I've found that since I took the title 'freelance programmer', I have fewer problems with either employees or their managers. I don't know why, but it may have to do with 'freelance' not having a lot of the nasty baggage carried by 'contractor' and (especially) consultant. I also noticed that calling myself a freelance programmer piques interest instead of garnering glassy-eyed stares :)

Like Mike, I also do my best to ensure that my clients become as self-sufficient as possible. This is not as altuistic as it sounds--I went freelance because I get tired of working on the same stuff for the same people for a long period of time. The quicker I can get a client to become (approximately) self-sufficient, the quicker I can move onto something new.

Ron Porter
Sunday, April 20, 2003

"Generally a good consultant is worth about 5 average employees"

That a bunch of ego-driven BS made by guess who???? A Consultant.

I've seen the exact opposite. Consultants who suck, write crap code, cash their check and move on to repeat the process!

Then the local dev group had to re-write everything they did!!!!!!!! Company is called

Monday, April 21, 2003

>That a bunch of ego-driven BS made by guess who???? A Consultant.

How about "Your mileage may vary" rather than 'ego-driven BS'?

>I've seen the exact opposite. Consultants who suck, write crap code, cash their check and move on to repeat the process!

Could be - for every great programmer - contractor, consultant or plain-old-employee, there's 10 that suck.

>Then the local dev group had to re-write everything they did!!!!!!!!

Sounds like you're shifting the blame entirely to the consultants/contractors - what was the process they were following?  How about specs?  What expectations were set?  Most clients don't realize that while a consultant may be an expert in some software dev domain, they do not have the intimate knowledge about a business that a full-time employee does.  It's just not possible - so consultants depend on the information given to them by their clients.  If it isn't complete, if it's inaccurate, their code is going to suck as far as your concerned.

Monday, April 21, 2003


You're right, the blame isn't 100% the fault of the consultants. Most of the blame goes to management! Then the rest goes to the consultants.

Monday, April 21, 2003

*  Recent Topics

*  Fog Creek Home