RE: Time to get serious -- MIDRANGE-L

Steve,

I apologize for my unclear statements. I think Michael said a bit better
what I meant.

I did not mean to imply you don't know your own industry or didn't have
business knowledge. I agree with you, general inventory management, for
example, is pretty much the same wherever you go. There are nuances to
handling grain inventory versus steel rod stock versus CDs. What I meant to
say is you would not just ask a programmer "Make me an inventory system"
without that programmer knowing anything about inventory management. You may
need to guide him in nuances in your specific industry requirements.
 
Evolving from a straight programmer (codes from the spec) to an analyst or
business analyst, or even software architect, implies that person has
knowledge of business practices and processes. Again, I agree with you that
specific industry knowledge isn't a hard requirement, but basics of the
business problem are known. Whether that knowledge comes from a textbook or
OJT is a different discussion. 

Again I apologize. I did not mean to demean you or anyone else. I heard a
different meaning of "programmer without business knowledge". It sounds like
you mean industry-specific knowledge, where I took it to mean general
practices knowledge.

Loyd

Loyd Goodbar
Senior programmer/analyst
BorgWarner
E/TS Water Valley
662-473-5713

-----Original Message-----
From: Raby, Steve (GE Advanced Materials, consultant)
[mailto:steve.raby@xxxxxx] 
Sent: Tuesday, March 01, 2005 09:18
To: Midrange Systems Technical Discussion
Subject: RE: Time to get serious


Hello Loyd

If you mean "just a person who codes" and nothing else, I'd be inclined to
let it pass. But are you talking about programmer/analysts and business
systems analysts?

I am an Analyst/Programmer, I was taken on, whilst contracting, by a very
enlightened manager who ran the IT department for a large chain of
Video/Music stores in the UK. All I knew of their industry was that you took
a round shiny thing put it in a machine and music came out of a couple of
boxes. It did not stop me from doing the job I was contracted to do. And it
was not only programming. I also worked for a software house who specialised
in packages for the motor trade, they seemed to think that all their staff
chose to work for them because they loved motor cars and motor racing, this
was not the case but they insisted in filling up your mailbox with this
stuff. 

In my view, technical skills are important, but the business knowledge is
just as, if not more, important. Would you trust "a programmer with no
business experience" program a MRP generation? Inventory control? GL/AP/AR?
Trucking route calculator? Trailer volume-fitting algorithms? 

Yes I would, GL/AP/AR just numbers, inventory is inventory, whether that be
CD's, whisky, trucks, tyres, steel, processed foods, plastic, paper,
whatever. ALL of these industries I have worked in, straight away, hit the
ground running whatever buzz words you want to use, and I DID MY JOB!

Unless very detailed flowcharts 

Flowcharts??

and specs

Specs??  

 are given to him (or her), that programmer
with no business experience will flounder. Why is as important as what and
how.

Yes I agree why CAN be as important as how, but not necessarily is, and I am
sorry and do not wish to start an argument here but that is a very demeaning
statement about thousands of talented freelance staff throughout the world.
Specs would be nice and are the way things should be done but in the real
world are not always given. Flowcharts? Haven't seen those in years, even on
big projects. And yet thousands of AP's around the world can still do the
job and not necessarily have an ounce of business knowledge to start with.

Steve

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.