Outsourcing

The consulting misnomer


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?

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...

10 comments
lolinardi
lolinardi

Can you give us some tips to keep up with technology. I can not write any code anymore since as you say, technology moves so fast, and lately I have not been programming. I need to learn pretty much from scratch. Last program I wrote was in VB5.0. I want to program again, actually I love to program... Where do I start. I live in Venezuela, here nobody teaches programming lang. Maybe Microsoft but it is unaffordable... HELP. Regards, I like your articles very much Loli

Sterling chip Camden
Sterling chip Camden

...if your last experience was VB and you still want to go back. I would recommend downloading an open-source platform and playing with it. That will only cost your time, and will build some valuable skills. Personally, I like the Ruby programming language (http://www.ruby-lang.org/) for learning a new language from scratch.

Sterling chip Camden
Sterling chip Camden

... to this thread before, I keep forgetting that this blog doesn't automatically notify me when new comments come in -- I have to subscribe to them just like everyone else. Good thoughts from everyone here. Certainly it's important not to waste talent (and money) on work that can be performed by just about anyone. My point was that the dividing line between what does and does not require special talent does not always fall neatly between planning and doing -- and from your comments it seems that you concur.

Locrian_Lyric
Locrian_Lyric

Not much to add. You *DID* however identify one difficulty in being a 'pure' consultant. Unless you get your hands dirty in the 'new stuff', your talents quickly become dated and less valuable.

apotheon
apotheon

. . . but, luckily, there are other ways to stay abreast of things and in practice than sitting around waiting for a client to require a particular skill. I find that, in practice, if your only practice with implementation comes from working for clients you won't get enough practice to matter. You need to stay in touch with the technologies on your own time if you want to stay relevant, regardless of whether you implement professionally, unless you're so thoroughly specialized that all you ever do is the same thing, and that's all you need to practice. I've never met an independent consultant (or even an independent contractor) that was [b]that[/b] specialized.

GeneS
GeneS

You need a pretty robust practice if you confine yourself only to consulting and not implementing. And, why are these discussions always focused on software. Hardware and infrastructure separate into "planning" and "implementing," also. In fact, for the small businesses I work with, it's a continuous mix of planning, implementation, and support. I essentially become the IT department for many small business. I am a member of the Independant Computer Consultants Association and their focus is on software, also. I would love to hear about other consultants who are itinerant CIO/Network Administrators, too.

Locrian_Lyric
Locrian_Lyric

Why the heck do companies pay consultants to do grunt-level implimentation?

apotheon
apotheon

I'm increasingly working with software, and decreasingly with network infrastructure, but I have done a fair bit of work in exactly the sort of specialty you identify. Ultimately, the point of separation between consulting and other contract work applies to more hardware-oriented work as well. With such work, however, the line is more clearly drawn -- and more commonly crossed by the expectations clients have for their consultants.

apotheon
apotheon

In fact, I tend to think that a lot of the architectural planning done in corporate shops would be better replaced by some high-level code -- perhaps taking a [url=http://dsoguy.blogspot.com/2007/01/programming-by-wishful-thinking.html][b]programming by wishful thinking[/url] approach to architecture planning. Software consulting would probably best be handled similarly, where the specification and architecture part comes up -- providing both the expertise and initial steps needed. The point where the line is crossed between "consultant" and "temp" is somewhere between there and writing code for interface buttons. I wouldn't say that a consultant should never write code -- just that (s)he shouldn't be writing user help documentation.

rclark
rclark

As I've said before, maybe not too well, there is a trend in the industry to over design solutions that are unworkable. It's widely reported that 80% of all major implementations fail to meet project goals. That doesn't mean that 80% of projects are scrapped, but that they don't do what they are suppose to. You ask why projects focus on software instead of hardware? That one I can answer. That is where the money is. Because every kid out of high school thinks they are sysadmins. And the hardware is standard enough to let them get away with it. Until you get into high performance systems, there is no real need for network tuning. Until you get into very large implementations, there is no real need for load balancing. So most networks are lashed together with marginal cables and they work, just not as well as they could. So from the point of veiw of the bean counters, why spend $250 per hour or $1K per day for a good consultant when the kid over in recieving can cable together the network at minimum wage? At the same time, we have these software geeks (IR1) that come in and do alot of voodoo that we can't see, and don't understand, but seems to make the company more competative, and the CEO and his friends think they have to have them, so we let them do their magic and we have a system. Don't understand it, but it works, sometimes, sorta..... And when it breaks, they don't know what is broken, but they know it's not giving them the answers it is suppose to, so more money and more time, and it works again.... The real problem is that most OO techniques are waisted on most problems. Why design and field a system that only experts can handle when most systems barely outlive their implementation schedules? Normalization, class definitions, abstraction, and all the specialized languages and addins are great for the 2% of the problems they are required for. But for the vast majority of problems, it just takes a crayon or a hammer. If the system is designed correctly, and it lives long enough, it will evolve into a package, if not, it will either be rewritten or tossed and another solution will replace it. There is a lot to be said for minimalist design and programming. Only using what is needed for the job. The KISS principle should be the gold standard, but as always, the ivory towers control the supply of new talent and their bread is buttered with complexity, so thats what they deliver. I have thousands of small systems that do their jobs very well and never need maintenance over decades of use. I have a few that were designed and fielded with the full object oriented design and implementation. Those frequently require changes, and because they were designed to do everything, they can usually be modified by data changes, but it takes a system expert to make the changes. And heaven help us if a user gets into the parameter files and changes something without knowing the underlying system logic.