"William Pursell" <bill.pursell@[EMAIL PROTECTED]
> wrote in message
news:a6a46d5b-2a47-46e4-80d6-b27b61579a23@[EMAIL PROTECTED]
> On Feb 18, 2:38 am, Ian Collins <ian-n...@[EMAIL PROTECTED]
> wrote:
>> Malcolm McLean wrote:
>>
>> > In practise it is easier to write the specification in code and cut
out
>> > the programmer entirely.
>>
>> When you write the specification in code, you place more value on the
>> programmer at the expense of others, like those so called "system
>> analysts".
>
> Perhaps I'm misunderstanding some terms here. When you "write
> the specification in code", does that mean write the specification
> by implementing it? In that case, you haven't cut out the
> programmer; you have become the programmer.
>
> If the term "programmer" simply means "person who converts someone
> else's design into machine readable form" while doing zero
> design themselves, well, that's just horrible. Does anyone
> really have such an unenviable task? Sure, I can see spending
> maybe a year or two doing that, and even doing that maybe
> 40% of the time for another few years, but surely no one
> can do that full time for long without going insane.
>
> How is it that people are using the term "programmer" in
> this thread? I think some definitions are missing. Is
> "programmer" a bad word to use on the resume these days?
>
The ambition of management is to have an entirely smooth process.
High level management decree that there shall be an IT system to, say,
computerise stock management in the warehouse.
The systems analysts, under middle management, then gather the
requirements
for the system, saying exactly what the program s must do, what data they
hold, what outputs they will give, even to the extent of designing mockups
of the stock viewing screens.
The specifications are then handed to the programmers who simply code
them.
"We consider programming to be a low-to-medium skill job" is a common
boast
you used to hear a few years ago. The spec is so good that coding it up is
purely mechanical.
Not so often will you hear that boast now. The problem is that the systems
analyst phase becomes so detailed that the requirements spec is
effectively
a programming language. However it is one that doesn't run, so it doesn't
have the discipline of actually having to work.
That's why IT projects notoriously go over budget.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
|
