4 ms·

Is there really 2 roles there? Who wants to design but not code or code but not design? I can't really imagine how you could even do either well without doing t

Is there really 2 roles there? Who wants to design but not code or code but not design? I can't really imagine how you could even do either well without doing the other.

douche 10y ago
You apparently have not encountered the "architecture astronaut" archetype[1]. Your final sentence stands; usually they can't. [1] http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html
- vonmoltke 10y ago
  The issue with "architecture astronauts" is that most problems in software just aren't complex enough to warrant formal design. The core failing of these people is that they impose unnecessary design complexity in order to force the design to be complex enough to warrant formal design. If the problem is inherently complex enough, particularly if it is multidisciplined, than it is the correct approach.
auxym 10y ago
It sort of reminds of mechanical engineering, where engineers sketch out the problem solution, do the calculations, and make sure the solution works. Then, they supervise drafters or technologists to produce the actual final product of engineering, drawings (2D/3D, paper/CAD, whatever). Of course, that's in larger orgs. Smaller places will typically have an engineer doing everything.
- vonmoltke 10y ago
  Of course, there is overlap there. Technician->engineer used to be a fairly common career path.
vonmoltke 10y ago
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 10y ago
  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 10y ago
    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.
- bpyne 10y ago
  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.
nickpsecurity 10y ago
High-assurance sub-fields have many examples where the code is easiest part as it's just implementing a verified spec. Others have plenty of work on both sides. Altran (formerly Praxis) is a nice example with many commercial successes: http://sdg.csail.mit.edu/6.894/dnjPapers/hall-correctness-by-construction.pdf http://sdg.csail.mit.edu/6.894/dnjPapers/hall-correctness-by...
JustSomeNobody 10y ago
So called software architects seem to tend towards design only.
- white-flame 10y ago
  It's a "turtles all the way down" issue, though. Software architects do the macro design, but they need to do that from an understanding of how it will be implemented, and the various lower level tradeoffs like consideration of the memory constraints of the target platforms. In order to implement that design the non-architect programmers need to micro-design their bits that they build, too. And those smaller bits also often need abstractions/mini-architectures that aren't part of the macro architecture.

Is there really 2 roles there? Who wants to design but not code or code but not design? I can't really imagine how you could even do either well without doing the other.

douche 10y ago

You apparently have not encountered the "architecture astronaut" archetype[1]. Your final sentence stands; usually they can't. [1] http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html

vonmoltke 10y ago
The issue with "architecture astronauts" is that most problems in software just aren't complex enough to warrant formal design. The core failing of these people is that they impose unnecessary design complexity in order to force the design to be complex enough to warrant formal design. If the problem is inherently complex enough, particularly if it is multidisciplined, than it is the correct approach.

auxym 10y ago

It sort of reminds of mechanical engineering, where engineers sketch out the problem solution, do the calculations, and make sure the solution works. Then, they supervise drafters or technologists to produce the actual final product of engineering, drawings (2D/3D, paper/CAD, whatever). Of course, that's in larger orgs. Smaller places will typically have an engineer doing everything.

vonmoltke 10y ago
Of course, there is overlap there. Technician->engineer used to be a fairly common career path.

vonmoltke 10y ago

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 10y ago
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 10y ago
  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.
bpyne 10y ago
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.

nickpsecurity 10y ago

High-assurance sub-fields have many examples where the code is easiest part as it's just implementing a verified spec. Others have plenty of work on both sides. Altran (formerly Praxis) is a nice example with many commercial successes: http://sdg.csail.mit.edu/6.894/dnjPapers/hall-correctness-by-construction.pdf http://sdg.csail.mit.edu/6.894/dnjPapers/hall-correctness-by...

JustSomeNobody 10y ago

So called software architects seem to tend towards design only.

white-flame 10y ago
It's a "turtles all the way down" issue, though. Software architects do the macro design, but they need to do that from an understanding of how it will be implemented, and the various lower level tradeoffs like consideration of the memory constraints of the target platforms. In order to implement that design the non-architect programmers need to micro-design their bits that they build, too. And those smaller bits also often need abstractions/mini-architectures that aren't part of the macro architecture.