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:
- how do we (as customers) detect this phenomenon?
- how do we (as consultants) solve this problem?
- what are the symptoms?
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?
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:
- Requests for proposals specifying what must be done
- Interviews between customer's technical group and the consultant
- Proof of concept phases
- Binding contracts with well-defined responsibilities and penalties
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.
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...
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 CodeMonkey
s, 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