[jalfresi]

Personally, I think the metaphor is quite apt. Obviously it is a metaphor so there isn't a complete mapping, but where do you feel the impedance mismatch is between the traditional architecture metaphor and software architecture? I'm genuinely curious to know, because I have found the metaphor to be strong enough that I read traditional architecture books to help me understand architecture and design in general in software development.

[kenbot]

They have almost nothing in common, and it's accidental when they do. For instance:

- Designing software in minute detail beforehand is generally neither necessary nor possible.

- It is impossible for someone to be a capable software "architect" unless they are an experienced software "builder".

- It is impossible for someone to be a capable software "builder" unless they are also capable of designing it.

- Software can be reused once built, and this matters while building it.

- Software is rarely "finished", but continues to grow over time.

- Software can be used by an unbounded number of users at the same time.

- Software can be reproduced infinitely.

- Software can be forked and incrementally changed.

- Anyone can design and build their own software, given some talent and a computer.

- The business motivations for software development are fluid, and often change rapidly over the course of a single project.

I could go on and on. As with many (most?) metaphors, it offers some superficial familiarity, but is ultimately harmful to your understanding.

Software is software. Understand it by reading about software and writing software.

[pessimizer]

Other than the top 3, these seem to be differences between software and buildings rather than software designers and architects. In addition, I don't think the first three are true. Lastly, these are distinctions without any actual difference in the context of the metaphor, where "architect" could have been replaced by 'novelist' or 'cabinetmaker' and no information would have been lost.

edit: to be more specific about the top three; the first rests on the word "minute" which can be as large or small as you want, depending on what you're trying to prove. The second may be true now, but that's largely because we lack a specific language of high-level software abstraction, so the only way to learn it is to build a lot of things (the general point of the original passage, btw.) The third is just wrong - plenty of people are useful for building parts of software who would have no ability to design a large application. I suspect that those people are a majority of the industry.

[kenbot]

The vast differences between software and buildings correspond to the vast differences in designing them.

In context here, "minute detail" is obviously a relative term comparing the requirements of software and architecture design.

You just made up the "specific language" thing. The reason we don't get unicorns to write software for us is they don't exist either.

There are many incompetent software devs out there, but I don't see how anyone can possibly build any amount of software _well_ without having an appreciation of how to design it. This is why I used the word "capable".

The thing is, even if some of these things were similar to architecture, it would be by accident. They are, on the surface, totally different fields. On a deeper level, they're still totally different. The onus is on you to show the linkage, if you believe it to be applicable.

[mtdewcmu]

Architecture is about designing buildings that not only serve their function, but are beautiful to look at. I think that's exactly why some people like "software architect." But, to me, "software architect" evokes grandiose, ornate software design, which serves no purpose, because no one sees it. Users see the software's UI, and the UI ought to be beautiful, but trying to make the internal design beautiful is not only unnecessary, it's counterproductive, because it gets in the way.

[walshemj]

it's a shockingly bad metaphor for software development.

I used to work for a top5 consulting engineer - architects some times just do the very high level design the consulting engineers actually turn this into a practicable design which is then built by the contractors and the navvy's.

And I am sure that my dept boss Dr Shair (one of the pioneers of the cable stay bridge design) would consider him self an engineer and not an architect