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?