In some engineering disciplines; the concepts of "design" and "engineering" are segregated ("implementation" may be further segregated, but that particular topic has already been done to death in the area of programming). It is occasionally argued that such separation is beneficial to software systems, as well.

In general (feel free to ReFactor this definition):

'''Design''' consists of the specification of requirements (functional, etc.) needed to satisfy the customer and other relevant external parties (the law, etc.) The job of a designer is to gather such requirements from various sources - asking customers directly, market research, academic research into relevant fields, DomainKnowledge, study of the law and of relevant standards and practices, and a bit of intuition/foresight, and produce a specification of some sort (the exact form is probably not important for this discussion). The designer is concerned with many HumanFactors - aesthetics, functionality, ease-of-use, fitness for purpose, and quality; the designer is ''less'' concerned with implementation details.

'''Engineering''' consists of the translation of these requirements into a technical specification describing a system which conforms to these requirements (which could be then implemented by persons knowledgeable in the craft). Again, the exact form of the technical specification is not important here. In many traditional engineering disciplines, the role of engineer is generally not concerned with things such as aesthetics or fitness-for-purpose; instead the engineer is concerned with coming up with a system (or specification) which is correct, safe, and cost-effective. The chief distinction between an engineer and a designer is that the engineer is personally (legally speaking) responsible for knowing said correctness and safety of the system. The processes of technical specification and other standard procedures exist so that the engineer can convince himself and others of this knowledge. In many fields it is possible for the engineer to be completely unrelated to the design process and only be responsible for the validation of the design.

I should emphasize that we are discussing ''roles'' here, not ''people''. It is not the intent to suggest that the same person who decides whether to use a marble or granite staircase cannot also compute the load on a particular beam.

----

'''Arguments for'''

* In some situations, the skills needed to do one job well are different than the skills needed to do a different job well. It is possible for one person to hold both sets of skills; but such individuals may be different to find.

* Segregation of duties is a well-known technique to reduce the chances of malpractice, fraud, errors, etc. Depending on the project, this may or may not be a concern.  ''It also helps to increase the TruckNumber''

* A single individual (or group) may be biased and may miss errors or potential problems that would be caught if another viewpoint was also involved.

----

'''Arguments against'''

* Such separation leads to inefficiency, especially on smaller projects. If the same person performs both roles; they may be more efficient in their work if they can integrate the functions. Likewise, with small teams, it may be a better division of labor to have the whole team jointly responsible for all aspects of the project than segregation of duties. (ExtremeProgramming and other agile methods embrace this philosophy).

* Sometimes, segregation of duties leads to the WaterflowModel, and/or processes where the information flow from designer to engineer is one-way, rather than bidirectional. On successful projects, it ''must'' be bidirectional; as many elegant (on paper) designs are not buildable (at least with current technology) or otherwise intractable or unsuitable.
** '''However''', this isn't necessary a problem with segregation of duties, but with how it gets implemented.

* Sometimes, the two roles regard each other with suspicion or contempt. In many organizations where marketing leads the design role, the programmers who perform the engineering (and implementation) roles may view themselves as doing the "real work" while the designers play golf and emit fatuous pieces of paper. (See ArchitectsPlayGolf; although the "architects" discussed on that page have more of an engineering role). Likewise, it's not uncommon for designers to regard themselves as the brains of the operation, and to regard the engineers and implementors as supporting roles (whose job it is to handle the mundane details).

* Separation increases the potential for a communications gap, misunderstandings, and misinterpretations.  Improving communications is always worthwhile, but has a cost (additional or more lengthy meetings, reviews, shadowing) and may incur delays.
----
CategoryEngineering