[self-interest] Architecture and Programming

[Richard]

cramakrishnan at acm.org wrote:
> I not sure i completely agree.  I think user interfaces to programs
> must satisfy functional and human needs in a way somewhat similar to
> architecture, but i don't think the structure of a program has to.

It doesn't if you're writing a shitty program. But then, building architects
don't have to satisfy human needs when they're working for most contractors.
It depends what you mean by "have to".

> Besides, architecture is about structuring space, whereas software
> architecture is about structuring ideas.

I disagree. I think that building architecture is about structuring ideas;
lines, forms, et cetera. Even 'space' is just an idea, whether you're
talking about spacetime or the human perception of space.

> Your analogy here presuposses that it makes sense to compare software
> architecture to real architecture!  :)
> 
> For the sake of argument, let's suppose it does make sense to compare
> software design to architecture.  Why do you compare the programmer to
> a draftsman?  Why not a structural engineer, or a mason, or whatever?

Any of those will do. I picked draftsmanship because it's at least
superficially similar to architecture and because people /did/ expect
architects to be trained as draftsmen just like they now expect software
architects to be trained as programmers.

And while my analogy presupposes that software and building architecture
compare, my argument doesn't. I know that programming is vastly different
from software architecture from first-hand experience. Personally, I love
design work, but I dislike implementation; I don't mind doing it but it's
much harder for me to be motivated to do it. As a simple example, consider
http://www.c2.com/cgi/wiki?OperatingSystemsDesign

> I don't even think architecture is a good metaphor for user interface
> design.  Industrial design is closer to UI design at the level of
> which it has to take into account the capabilities and limitations of
> humans.

Metaphor-driven design is a bad idea. And you have to keep in mind that
there is a world of difference between horrible industrial design (which
is standard) and good industrial design. Just look at the Kinesis keyboard
for a clear example. And Christopher Alexander, the quintessential
architect, has written extensively about furniture design.

http://www.c2.com/cgi/wiki?KinesisKeyboard

http://www.math.utsa.edu/sphere/salingar/Chris.furniture.html

> > I read a good paper (can't remember where) on the uselessness of software
> > reuse which explains that while the abstract architectures in two different
> 
> If you remember the reference, I'd like to hear it.

Hmmm, imagine that; I actually did find it.

http://c2.com/ppr/ams.html

The software development community at large also needs to recognize that
traditional approaches to reuse
are essentially archaeological approaches. In archaeology, software artifacts
are dumped into repositories
and various carrots and sticks are employed in the attempt to get developers to
scavenge through them.
Let's ask ourselves - and answer honestly - how much use would a repair dispatch
domain object called
"work order" be to developers of a delinquency collection application, even if
it contained considerable
workflow functionality? Not much, it must be admitted; potential reusers would
have to spend too much
time separating out the domain specifics. This is why, despite four decades of
hype, software archaeology
has yet to produce meaningful levels of reuse. The better approach is to
recognize and separate domain
specifics from generic behaviors at design time - an architectural approach.
This in turn requires a
common, architectural understanding of what is generic and what is
domain-specific.