× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Programmers VS Consultants
  • From: DAsmussen@xxxxxxx
  • Date: Tue, 23 Nov 1999 19:32:28 EST

Roger,

In a message dated 11/22/99 4:36:49 PM Eastern Standard Time, 
RBoucher@stanpac.com writes:

Run for cover?  Maybe, maybe not.  You've made some good points, which I'll 
address in the text of your message.  I couldn't let this thread go by 
without putting in my $.02 in, though!  Just remember my own quote about the 
difference between a consultant and a contractor -- "A consultant's job is to 
eliminate the need for their position, a contractor's is to perpetuate that 
need."  So RANT MODE(*ON)...

> I hate to say this, and I don't want to generalize, but my time spent in a
>  very large MIS shop led me to the conclusion that if you want something 
done
>  right, you do it with in-house programming staff.  If you want to slap it 
in
>  and not care what kind of mess is left behind, go ahead and use 
consultants.
>  If you need technical expertise you don't currently have in-house, hire a
>  consultant as a technical resource and train an in-house person to maintain
>  and support the application (and preferably develop it, too!).  The 
in-house
>  staff needs to live with the results, but consultants often don't.  Success
>  is viewed as did they get it in and does it work, end of review.  And
>  remember... EVERYTHING needs maintenance... this is not a put it in and
>  forget it kind of business we are in (unless of course you are on an AS/400
>  <g>).

Not to be ugly, but WRONG!!!  I specialize in large clients, and you have 
apparently worked for "the best of the best."  I have yet to see a client 
whose in-house staff could even approach my own ability in simple RPG and CL 
programming -- let alone ILE.  No brag, just fact and an ugly one given that 
I work in CASE tools most of the time and my "native" programming skills have 
suffered accordingly.  My last site mandated the use of the AS/Set CASE tool 
unless absolutely unsuitable for the task because the coders couldn't read 
the RPG that AS/Set generated nor the most simple CL program.  The major 
topic of discussion at most large sites isn't ILE vs. OLM, JAVA vs. RPG, 
mirroring vs. RAID, or the relative merits of OO vs. procedural code -- it's 
the fact that it's "Chicken Day" in the cafeteria.  Most in-house staff have 
the "get it done and damn the documentation" attitude -- anathema to 
upgrading packaged software that's been modified.  Productivity?  That's the 
thing we're supposed to keep low lest management come to expect it.  
Personally, I never thought I'd see the day when IS became an 8-5 job -- most 
developers at large corporations do just that these days (they pay the 
consultants/contractors to handle the overage).  Not to paint with a broad 
brush, since some large sites at which I've worked _DO_ have a superior 
staff, but most have not.  My major measurement of a site's skillset is 
whether or not I learn anything from the staff -- after over five years on my 
own, I think I'll keep going to COMMON...

EXCELLENT consultant strategy, though.  That's what we're for, you know.  
SHORT-TERM is the operative word.  If you have development standards, enforce 
them with the consultants/contractors.  If you don't have development 
standards, come up with some _BEFORE_ you hire the aforementioned -- or make 
the consultant's first job  writing your standards if their knowledge is in a 
specialized area.  Third parties need to be managed, often closer than does 
your own staff.  If you don't know what the contractor is doing, chances are 
he/she doesn't either...

>  With all that said I know there are certainly very good consultants out
>  there who care very much about the quality of their work and what they 
leave
>  behind.  There must be, because when I go out on my own some day I know 
that
>  I won't be the ONLY one out there who feels that way!!  It's just that I
>  haven't run across very many... yet.

To reiterate what others have said, quality of work is all that I have to 
sell.  If you work somewhere for years and do a bad job, where are you going 
to go next?

>  But this brings me to a real pet peeve of mine:  RANT(*ON)
>  The people who budget for hiring need to learn that MIS is where it's at.
>  This is not a fad we are dealing with here, it is the future.  Stop trying
>  to avoid head count and start trying to build a good solid staff of MIS
>  personnel to allow you to grow without quite so much pain.  And you KNOW 
the
>  pain I'm talking about!  My experience, again, tells me that trying to
>  minimize the headcount of an MIS department is the worst way to go about
>  getting good results.  In the long run you will only double the work for an
>  already beleaguered staff.

If you'll check the archives, I've ranted about this very same gripe in the 
past.  Heck, if it weren't for head count, I'd never have gone independent in 
the first place.  As a consultant, I resent being brought into a workplace 
merely because the company refuses to hire enough people to do the job 
effectively.  The latter leads to nothing but hard feelings and increased 
pressure on _ME_ to perform at twice the level of the employees.  If you need 
more people, hire them.  If you need short-term or specialized BPCS help, 
hire me.  _DON'T_ bring me in to fill in for the people that you should have 
hired in the first place!  There was absolutely no reason for my last primary 
client to keep me for nearly five years, other than the fact that they were 
concerned with head count -- they could have hired more heads for what they 
paid me.

>  The bottom line is nobody cares more than the people who have to live with
>  it.

True but, I always code as if I'll have to come back some day.  Given that I 
write so much code that I can't remember what I did yesterday, let alone last 
week, I always try to write solid stuff that is well documented.  If only the 
"full-timers" did the same...

>  RANT(*OFF)
>  
>  Running for cover because I know there must be tons of consultants on this
>  list,

Good points, all.  Yes, there are people that will take advantage.  No, they 
don't last very long if everyone checks references.  My list of area people 
that I _won't_ subcontract is _MUCH_ longer than my list of people that I 
will.  In fact, after nearly 20 years in this crazy business, I still can 
count the number of people that I'd even _RECOMMEND_ for _ANY_ job without 
using my toes.

Consultants are _NOT_ contractors.  As was said earlier, ignore the business 
card and judge based upon ability...

RANT MODE(*OFF) (but I feel better)

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"Success is not the result of spontaneous combustion.  You must first set 
yourself on fire." -- Fred Shero
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.