Quote:

Original post by freakchild Yeah, but if the instructions are so precise then an experienced programmer put them together anyway. Someone somewhere did some programming in order to get to this point, that person wasn't painting by numbers and they were sufficiently skilled to specify enough of a program to pass it to someone else (i.e. they weren't replaceable).

You just missed the point. The programmer who produced the instructions isn't expendable. The coder who gets given those instructions next is.

Quote:

Original post by jbadams You just missed the point. The programmer who produced the instructions isn't expendable. The coder who gets given those instructions next is.

OK, I can agree that a coder in the sense that Oluseyi defined him is an expendable resource. I just haven't met anyone working professionally who meets that description (outside of transitional ramp-up exercises, which are meant to be didactic anyway). I don't think I've seen any job reqs for "human encoders" either; what sort of companies do they work for? I'd guess really big, process-heavy ones; maybe IBM or Sun has some use for people like that.

Alas, I've exhausted my limited rhetorical powers in arguing why building bridges and building software are inherently different exercises, but I happened across an interesting article making much the same points. I offer it in lieu of further sparring :-)

And for the record, I don't endorse the view quoted at the bottom of that article (and mentioned elsewhere on this thread), that software is the most complicated of engineering disciplines. Our discipline is built on a well-defined logical system (a computer); electrical engineering, applied physics, et cetera need to concern themselves with an infinitely more complicated system: nature.

I'm glad we're all friends again! [smile]

Currently, Muse et al are right: by the time sufficiently precise instructions are given, the software is essentially written. However, this is only so because our tools and understanding of the discipline are primitive. As we obtain more sophisticated abstractions, and particularly notation systems, then high level design can be "sufficiently precise instructions" implemented by fairly interchangeable implementers - think about how architectural blueprints have come to perfectly describe every aspect of the construction of a building, no matter how large or complex, to the point that any certified contractor and construction workers can build the physical structure, any certified contractor and electricians can complete the electrical systems, etc.

It's inevitable.

Quote:

Original post by Muse Alas, I've exhausted my limited rhetorical powers in arguing why building bridges and building software are inherently different exercises, but I happened across an interesting article making much the same points. I offer it in lieu of further sparring :-)

I've read that article (incidentally, it's written by Promit's new boss). It only details the current complexities (and lack of tools and techniques sophistication) in software development.

Quote:

And for the record, I don't endorse the view quoted at the bottom of that article (and mentioned elsewhere on this thread), that software is the most complicated of engineering disciplines. Our discipline is built on a well-defined logical system (a computer); electrical engineering, applied physics, et cetera need to concern themselves with an infinitely more complicated system: nature.

Agreed.

Quote:

Original post by Oluseyi I'm glad we're all friends again! [smile]

Was that ever in question? Without good argument, we'd never get anywhere.

Quote:

Original post by Oluseyi Currently, Muse et al are right: by the time sufficiently precise instructions are given, the software is essentially written. However, this is only so because our tools and understanding of the discipline are primitive.

I can agree to that.

The following is a viewpoint by myself, and myself alone: I think that when the time comes that design tools are good enough such that their product can be " implemented by fairly interchangeable implementers" - we'll have automated the job of those implementors... again, making them realistically non-existant minutia.

BAM! I WIN! (j/k)

Your logic, sir, is impeccable. I graciously concede defeat! [smile]