[vonmoltke]

See proper engineering and the distinction between an engineer, a technician, and an assembler. There is overlap, of course, but designing and producing the product is a collaboration between all three. The engineer is primarily responsible for designing the system, the technician for helping the engineer translate the design into a realized system, and the assembler for actually realizing the system.

[wtetzner]

Well, but it's a bit weird with software. The "realized system" typically comes out of a compiler. When designing the system, the computer can often take your design and turn it into a realized thing.

In fact, we even have software called an assembler :)

Of course, it all depends on what level you're doing design at, and what level your language(s) work at. But the point is that those 3 roles aren't necessarily are fulfilled by humans when working with software.

[vonmoltke]

I didn't say they necessarily were all fulfilled by humans. My point is that they are not necessarily all fulfilled by one human. Apropos of the comment I made in response to the "architecture astronauts", the complexity of most software projects is such that the design, from a technical standpoint, is a pretty small portion of the total effort required. In that case it makes sense for the technician to be the designer as well, which is something that often happens in the trades on simple jobs.

That does not mean that there can't or shouldn't be a distinction between the engineer and the technician on sufficiently complex projects. That is, they don't need to be filled by people who could perform either role, as the original comment I was replying to implied. That point was either miscommunicated in my original post or rubbed some people the wrong way.

[adrianratnapala]

The thing is that engineers produce and maintain documents. Specifically they produce source documents from which the end product has been derived.

That's exactly what a coder does.

There are some fields (draftsman, typist, others?) of people who created fine documents based on vague documents from engineers, architects etc. So in principle you could have a similar distinction between software archtects and coders. But it is exactly those document-gruntwork fields which have been transformed most by computers.

[bpyne]

Are organizations still trying to move in that direction when engineering software products? I know it's been tried for decades now. But my limited experiences in organizations that tried it have not been very good. I'm curious if any organizations have made it work.

[vonmoltke]

At the risk of drawing accusations of using the "No True Scotsman" fallacy, I'd say that most attempts have been trying to force-fit that type of style on projects that don't warrant it. That happens in all areas of engineering, though. The specific problem in software, IMO, is that too many projects are considered software "engineering" that shouldn't be, because they just aren't complex enough.