Consultants Dont Code

This is when the high-powered and high-paid people brought in to share their wisdom with you haven't written any code in so long that their advice constitutes nothing but vague platitudes and things they know only from second-hand experience.

Given the large number of consultants on Wiki I have three questions:

-- AnonymousCoward

If the consultant is there to implement a project (that is, code) you (the customer) can probably detect ineptitude quickly, especially with a proof-of-concept phase and references. As consultants, we can be forthright about what we know and what we don't know; let others make their vague platitudes--let our work stand for itself.

Sounds like you're trying to define an AntiPattern. Maybe we should restructure the page?

-- AllanBaruz

My goal with this page was to stimulate discussion on how to identify a potential problem with (internal or external) consultants and how the consultants can go about resolving the problem. As a consultant how does one avoid becoming a SeagullConsultant who has spent so long consulting that s/he no longer has a clear idea what it means to be doing real day-to-day development with the relevant technologies and issues.

This is especially likely to happen if one tends to be parachuted into projects to resolve issues quickly and then leave.

Okay. I'm not sure I have the experience to talk about this kind of consulting. Perhaps you could define a situation in which a SeagullConsultant comes in, as a concrete example for us to bat around? My experience as a consultant is mostly as a troubleshooter. The customer usually has a defined, specific problem, and I am sent to implement a solution to it that my company supports.

But when has lack of experience ever stopped me from talking? er, typing? Here are things I think might help that I've heard vague reports of:

If the consultant has been foisted onto your group by management, then there's not much you can do, is there? Make sure you have version control or backup copies and CYA--communicate your apprehensions.

--AllanBaruz

Are we being completely honest here? Is it that consultants don't code, so they don't know how to be effective in a coding environment, or is it that consultants don't code and yet they are still able to be effective at certain kinds of development problems, perhaps more so than someone who codes all the time? A consultant's effectiveness is (or should be) way more visible than a full time employee's, which should work via feedback to keep consultants sharp. Why might that not be happening? Why might a professional coder perceive it not to be happening?

See also: http://www-106.ibm.com/developerworks/ibm/library/i-extreme2/ for an example of this problem and one possible approach to solving it.

How does one go about SurvivingConsultantStatus? At some point it might be nice to go back into the real world of development as part of a team working long-term on one project instead of parachuting into an organisation and then leaving. Has anyone had to make this transition? What was it like?

See also: http://www.rc3.org/cgi-bin/less.pl?arg=4628 wherein Rafe (at the end of an entry about the ThePetstoreFiasco) says that the core skill for a consultant is willingness to travel and claims that most consultants are mediocre programmers.

Actually, I've found the opposite. The consultants/contractors I know are FAR, FAR better developers than most of the permies we come across. The reasons for this I think are many, but start with the fact a lot of permies are SoftwareLabourers and a lot of them stay in one place a long time and don't get exposure to a lot of environments.

Sadly, these two assertions are hardly contradictory, especially in heavily promoted systems such as VisualBasic and JavaLanguage where thousands of half-trained EnlisteeCoders have been set loose on the industry. - JayOsako

It's like the BoiledFrogs thing - if you've been there while the environment degrades you "get used to" things like: makefiles that don't do builds properly, people banning emacs because it's not secure, whacky buggy little shell scripts to do things UNIX does perfectly well if you knew the proper route (or had the manual pages installed), compilers that are so old they don't support "bool". Things like that. Because they creep up on you slowly.

You also don't get to see completely different industries working. Some of the people here have only ever been software engineers in this building under the (rather oppressive) regime here. They were shocked by my rather profligate creation of new files (a C and a H per object). Because as far as they know C++ programs always consist of the same half-dozen files, copied from the gold master template and customised a bit. It's a brave engineer here who starts a new function...

--KatieLucas

CDC swings both ways. Firstly, shops like ObjectMentor decree that all consultants shall cut code [every week? every project?] to keep them in touch. However, technically successful projects like ChryslerComprehensiveCompensation run with the rule that the consultants shall not _need_ to cut the code. The project can keep running if they stop at any time.

Put them together, and the consultants should write enough code to challenge their ability to dispense wisdom to the CodeMonkeys, and at the same time they should not always assume the burden of writing the hardest code. That's the code that the team should learn the most from.

I will follow this advice just as soon as I become financially secure enough to be chronically expendable. --PhlIp

CategoryConsulting, CategoryAntiPattern

EditText of this page (last edited October 14, 2005) or FindPage with title or text search