Follow this blog:
RSS
Email Alert

IT Consultant

The consulting misnomer

Takeaway: My previous post (Getting beyond the ‘bull’ perception), spawned an interesting discussion about “consulting” vs. “contracting”. Both apotheon and Richard_RPU made the point that consultants should be paid for their expertise, rather than for implementing a solution. Ideally, a consultant helps the client to define their requirements, identify problems, and chart their course [...]

My previous post (Getting beyond the ‘bull’ perception), spawned an interesting discussion about “consulting” vs. “contracting”. Both apotheon and Richard_RPU made the point that consultants should be paid for their expertise, rather than for implementing a solution. Ideally, a consultant helps the client to define their requirements, identify problems, and chart their course — then leaves the implementation details to those who are less capable of seeing the big picture (and who are presumably paid accordingly).

Is that how it goes with your projects? I consult on software development, and very few of my projects work out that way. Oh, yes, I perform all of the functions listed above, but then the client invariably says, “You know, we just don’t have the expertise here to even get started on implementing what you recommend. We need for you to lay the groundwork for us so we can build upon it.”

So I typically create the foundation classes and some utilities, and usually implement one or two usage examples before I turn my work over to application programmers. If issues arise later, or they need to extend the foundation, I’m usually called in to do that part, too.

Does that make me part consultant and part contractor? Maybe so. But is there anyone out there who consults on software development without writing any code? If so, how do you know what you’re talking about? Programming technology advances rapidly — and if you don’t keep your hands in it, you’re soon out of touch.

Furthermore, a large part of “the big picture” for software resides in its basic architecture. Thus, the division between writing a high-level design and writing code becomes artificial, for certain kinds of code. A more natural division of labor arises between creating the abstract, highly reusable framework and generating application instances that use it.

Software development consulting may be unique in this respect, however, because software contains significant layers of abstraction. I can see how security, infrastructure, or a number of other areas more easily divide between planning and doing.

What do you think?

Get IT Tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.

Chip Camden

About Chip Camden

An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology.

Chip Camden

Chip Camden
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 blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.
10
Comments

Join the conversation!

Follow via:
RSS
Email Alert