Programming is not as much fun/more fun than it used to be.

[Cristiano Sadun]

What do you consider Architecture (which I consider the closest
analog to Programming)?

Check out http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf -
I couldn't say it better.

I think that--particularly with regard to UIs--there are some very
definite creative aspects to programming.

Engineering is profoundly creative - but not an art. Art isn't - by far -
the only creative of human endeavours (and often engineering is often even
more creative, since it is subject to stronger constraints). Building a
motorcycle engine's as bit as creative as painting a canvas.

 

[Chris Sonnack]

Check out:
http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf -
I couldn't say it better.

| Forbidden
| You don't have permission to access /ieeeSoftware/ on this server.

So I have no idea what you or he would say. :-(

Engineering is profoundly creative - but not an art.

No, I agree completely.

Art isn't - by far - the only creative of human endeavours...

Right again. Creative != Artistic

...(and often engineering is often even more creative, since it
is subject to stronger constraints).

I'm not sure what constraints have to do with creativity, nor am
I sure I agree they are necessarily stronger in engineering. A
lot of artists operate under severe constraints, too.

One might argue that art is more creative, because you create from
the "whole cloth", whereas there are many tools and techniques in
Engineering.

Building a motorcycle engine's as bit as creative as painting
a canvas.

Ah, no, can't agree with you there (unless you mean designing an
engine from scratch).

 

[Chris Sonnack]

Well, for starters, the term "architect" literally means
"chief technician."

Sure, but I'm talking about those guys who design new buildings.
Art combined with Engineering!

This may lead to another interesting discussion as to
what is "architecture" in the domain of software.

....talking about those guys who design new [programs].... (-:

There are many analogs. Both start by gathering requirements from
the client. Both proceed by creating prospective designs on paper
or using RAD tools (e.g. little building models/software prototypes).
Both require a knowledge of the science & technology relevant to
the craft. Both create a 'new' thing not quite like any existing
one (but often based on, or paying homage to, existing ones). Both
can require a team to implement (if they are big), but both may be
done by one (if they are small). Both are (or can be) *implemented*
by "builders" rather than the "designer". Both (if big) can suffer
from inertia--the difficulty of changing the design late in the game.

Of course there are striking differences, too. Making copies of
the product is trivial for software, but expensive for buildings.
And if your software crashes, ***usually*** no one is actually
hurt or killed.

For starters, let me paraphrase Christopher Alexander

Alexander is well-known to some programmers, too, and there is
even an "alexandrian patterns movement" in the community. Check
out "PatternsOfSoftware" by Richard P. Gabriel.

" ... a large part of the "structure" of a building
or a town consists of patterns of relationships...

Absolutely. I mentioned an interesting, intellectual film here
recently, MINDWALK. One of my favorite parts is where they talk
about relationships. It starts with physics, but ends up about
how a musical chord is strictly the *relationship* between the
notes. No relationship, no chord. And melody is a relationship
between notes and time.

Saying that, for example, if the aisle were not aligned in a
particular way it would no longer be an aisle, or if the pews
were facing away from the altar it wouldn't really be a church,
would it?

Well, honestly, my definition of "church" is function-based,
not structure-based, so I'd disagree with this as stated. I
see the point, though.

Bt extension, I would claim that "software architecture"
should be concerned with the relationships of the elements
which comprise a program (or a system of cooperating
programs, or a system of cooperating systems) rather than
the elements themselves.

Well, I think the relationships are very important, but so are
the elements!

And we do concern ourselves with those relationships when we
talk about encapsulation, coherence, cohesiveness, inheritance
and dependancies. (Or did you mean other types?)

 

[Chris Sonnack]

| Forbidden
| You don't have permission to access /ieeeSoftware/ on this server.

So I have no idea what you or he would say. :-(

What I didn't notice is the second window behind the 404 window
that loaded the PDF. Someone's webserver has a security issue,
I think.

Interesting article, but he's really talking about "Architect"
and what that means. What I'm getting at is that I see the
process of Architecture (specifically: designing a new building
or structure) as having many analogs (detailed elsethread) to
the process of creating a new program.

And that's ALL I was referring to. (-:

 

[Nick Landsberg]

Nick Landsberg wrote:

Well, for starters, the term "architect" literally means
"chief technician."

Sure, but I'm talking about those guys who design new buildings.
Art combined with Engineering!

This may lead to another interesting discussion as to
what is "architecture" in the domain of software.

...talking about those guys who design new [programs].... (-:

There are many analogs. Both start by gathering requirements from
the client. Both proceed by creating prospective designs on paper
or using RAD tools (e.g. little building models/software prototypes).
Both require a knowledge of the science & technology relevant to
the craft. Both create a 'new' thing not quite like any existing
one (but often based on, or paying homage to, existing ones). Both
can require a team to implement (if they are big), but both may be
done by one (if they are small). Both are (or can be) *implemented*
by "builders" rather than the "designer". Both (if big) can suffer
from inertia--the difficulty of changing the design late in the game.

Of course there are striking differences, too. Making copies of
the product is trivial for software, but expensive for buildings.
And if your software crashes, ***usually*** no one is actually
hurt or killed.

For starters, let me paraphrase Christopher Alexander

Alexander is well-known to some programmers, too, and there is
even an "alexandrian patterns movement" in the community. Check
out "PatternsOfSoftware" by Richard P. Gabriel.

" ... a large part of the "structure" of a building
or a town consists of patterns of relationships...

Absolutely. I mentioned an interesting, intellectual film here
recently, MINDWALK. One of my favorite parts is where they talk
about relationships. It starts with physics, but ends up about
how a musical chord is strictly the *relationship* between the
notes. No relationship, no chord. And melody is a relationship
between notes and time.

Saying that, for example, if the aisle were not aligned in a
particular way it would no longer be an aisle, or if the pews
were facing away from the altar it wouldn't really be a church,
would it?

Well, honestly, my definition of "church" is function-based,
not structure-based, so I'd disagree with this as stated. I
see the point, though.

Bt extension, I would claim that "software architecture"
should be concerned with the relationships of the elements
which comprise a program (or a system of cooperating
programs, or a system of cooperating systems) rather than
the elements themselves.

Well, I think the relationships are very important, but so are
the elements!

And we do concern ourselves with those relationships when we
talk about encapsulation, coherence, cohesiveness, inheritance
and dependancies. (Or did you mean other types?)

I was thinking at a different level than this.

For example, many "viewgraphware" architects will
claim things like "Our architecture is .NET,"
or that "Our architecture is a Sun Solaris server
running an Oracle back-end accessed by Win2000
PC's over a 1 GB LAN, etc. etc."

For me this has as much relevance to the actual
software architecture as if a building architect
had said "Our architecture is reinforced concrete."

The decision about how to apportion functionality
between front-end and back-end machines (how to
encapsulate it in the right place) and what
relationships there are between the pieces
is probably more important. Similarly, on the
back-end server, I may decide to further apportion
the functionality to specific individual tasks
or threads (or I may not). These, in fact, may
communicate between themselves to do some part
of the functionality. For example, an authentication
server process may be queried before doing anything
else, then the database is queried, etc. Alternatively,
one may choose for the authentication server to be
queried by the PC's first, and then the PC's send the
query out to the database. The "relationships"
between the client-PC's and the back-end is quite
different in the two case. The "architectural
tradeoffs" have to be clearly understood for
each alternative.

My belief is, again, that this apportionment of
logical tasks is part and parcel of a complete
software architecture. Conceptually, it is
no different than the principles you mentioned
above (encapsulation, coherence, cohesiveness, etc.)
but they are hardly ever applied to the larger picture
in my experience.

 

[Gerry Quinn]

What do you consider Architecture (which I consider the closest
analog to Programming)?

The same would apply, although I think architecture is more analogous to
software design.

I think that--particularly with regard to UIs--there are some very
definite creative aspects to programming.

Of course. There's nothing un-creative about engineering.

- Gerry Quinn

 

[Cristiano Sadun]

I'm not sure what constraints have to do with creativity, nor am
I sure I agree they are necessarily stronger in engineering. A
lot of artists operate under severe constraints, too.

You're right, my statement was perhaps too generic. What I was thiniking
about - for the "constraint" bit - was vaguely regarding the existence of
external requirements, outside the control scope of the engineer, which
have to be met in order to produced a satisfiable result; whereas an artist
tends often (not always) to define his/her own constraints. Which may still
be as hard as they get, but the difference would be in self-imposition (and
thus the possiblity of their relaxation if they turn out to be set too
high) as opposed to external imposition.

Still, mine's still just a hint of an idea, and I could well end up
discarding it after giving it more consideration.

One might argue that art is more creative, because you create from
the "whole cloth", whereas there are many tools and techniques in
Engineering.


Ah, no, can't agree with you there (unless you mean designing an
engine from scratch).

Oh. That was a reference to Pirsig's "Zen and the art of motorcycle
maintenance" - whose discourse on different types of estethics (and the
idea of "creativity" that derives from them) I enjoyed quite a lot many
years ago.

Alas, this is a soft-eng group so I have to stop here.

 

[Cristiano Sadun]

Interesting article, but he's really talking about "Architect"
and what that means. What I'm getting at is that I see the
process of Architecture (specifically: designing a new building
or structure) as having many analogs (detailed elsethread) to
the process of creating a new program.

Well, the idea of (software) "architecture" as "nothing more special than
the first level of design" is something I relate to.

There's also the bit about how a building architect's role is different
than a software architect's role (the latter, at least, as it's often
perceived: someone with deep experience, insights and instincts in the
technical aspects of things. Where the construction architect has a
structural engineering instead to make things actually work).

Therefore, I consider construction architecture as an useful source of
inspiration, but a metaphor which reaches only so far.

 

[Chris Sonnack]

What I was thiniking about - for the "constraint" bit - was vaguely
regarding the existence of external requirements, outside the
control scope of the engineer, which have to be met in order to
produced a satisfiable result; whereas an artist tends often (not
always) to define his/her own constraints. Which may still be as
hard as they get, but the difference would be in self-imposition
(and thus the possiblity of their relaxation if they turn out to
be set too high) as opposed to external imposition.

Understood.

However, I think you're comparing two different things, because you
are seeing artists as defining their own work and engineers as working
for spec. Artist, too, can work for spec (and then the constraints
can be VERY severe in terms of money, goals, materials, etc.), and
programmers sometimes define their own work.

Try this: compare artists and engineers working for spec.
Or: compare artists and engineers working for love. (-:

Still, mine's still just a hint of an idea, and I could well end
up discarding it after giving it more consideration.

Or modifying or enriching it. Ain't discussion great?

Oh. That was a reference to Pirsig's "Zen and the art of
motorcycle maintenance"...

(Heh. I wondered if that's what you had in mind!)

... - whose discourse on different types of estethics (and the
idea of "creativity" that derives from them) I enjoyed quite
a lot many years ago.

Many of us did! However, I'm not sure I equate *appreciation* of
esthetics with true artistic creativity. Artists create something
from the "whole cloth". Building something from a design--no
matter how elegant, esthetic or pleasing--isn't art (to me!).

 

[Chris Sonnack]

Well, the idea of (software) "architecture" as "nothing more
special than the first level of design" is something I relate to.

Well, I can certainly agree that "architecture" includes the "first
level of design"! But I'd say that first level is pretty special!

Creating something from nothing is (to me) special.

However, this may touch on a difference in perception we have.
See [A] below.

There's also the bit about how a building architect's role is
different than a software architect's role (the latter, at least,
as it's often perceived: someone with deep experience, insights
and instincts in the technical aspects of things. Where the
construction architect has a structural engineering instead to
make things actually work).

If I follow, you're saying the software architect has greater
technical knowledge of the construction of his design than does
the building architect?

I think you might want to speak with a few building architects! (-:

From what I've experienced, they do tend to know a great deal
about the technical requirements and their designs include a
*lot* of the constructive elements (if not all!). (If you look
at the detail drawings of buildings, they often include where to
put the bolts.) Also, building architects use engineering
knowledge to insure their designs will actually work.

[A]
Of course, we may be drawing a line in a different place. When I
talk about the architecture of a building, I *am* talking about the
full design (including construction details), not just some drawings
or models of what it should *look* like.

To me, building architecture is the full design. Just as the full
design of an application is "software architecture".

So maybe our definitions differ.

Therefore, I consider construction architecture as an useful source
of inspiration, but a metaphor which reaches only so far.

Don't they all! (-:

 

[Chris Sonnack]

I was thinking at a different level than this.

And I think "architecture" can (validly) mean multiple things....

For example, many "viewgraphware" architects will
claim things like "Our architecture is .NET,"
or that "Our architecture is a Sun Solaris server
running an Oracle back-end accessed by Win2000
PC's over a 1 GB LAN, etc. etc."

I hear/see the same thing often. I think that's a valid use
of the term, although it's not what we--as programmers--usually
mean when we use it.

For me this has as much relevance to the actual
software architecture as if a building architect
had said "Our architecture is reinforced concrete."

Or perhaps, more usefully, "Our architecture uses cantilevered
terraces, lots of windows and large open spaces." Both, to
me, are descriptions of the *important* components of a large
design.

The decision about how to apportion functionality
between front-end and back-end machines (how to
encapsulate it in the right place) and what
relationships there are between the pieces
is probably more important.

Similar to where to put windows, how large to make spaces, etc.

[...] The "relationships" between the client-PC's and the
back-end is quite different in the two case. The
"architectural tradeoffs" have to be clearly understood
for each alternative.

I agree completely, and I see (building) architects making the
same sorts of decisions. As you say, that's really what the
architecture is about. The use you mention at top is just an
"outsiders" casual way of describing something.

I suppose I could argue that, the guy who (presumably after
considering all those important relationships) originally
designed the "Sun Solaris server running an Oracle back-end
accessed by Win2000 PC's over a 1 GB LAN, etc. etc." was
the Architect and the "outsiders" are just referring to his
(or her) work in a manner most people will grok.

My belief is, again, that this apportionment of
logical tasks is part and parcel of a complete
software architecture.

I agree! I only add that selection of those construction
materials *is* part of the analysis and design.

Conceptually, it is no different than the principles you
mentioned above (encapsulation, coherence, cohesiveness, etc.)
but they are hardly ever applied to the larger picture
in my experience.

Sad, but often true.

 

[CBFalconer]

.... snip ...

I suppose I could argue that, the guy who (presumably after
considering all those important relationships) originally
designed the "Sun Solaris server running an Oracle back-end
accessed by Win2000 PC's over a 1 GB LAN, etc. etc." was
the Architect and the "outsiders" are just referring to his
(or her) work in a manner most people will grok.

Does the word 'grok' really exist, or is it purely an artifact of
Heinleins imagination in "Stranger in a Strange Land"?

 

[Nick Landsberg]

Nick Landsberg wrote:

[ Much Snippage ]

[...] The "relationships" between the client-PC's and the
back-end is quite different in the two case. The
"architectural tradeoffs" have to be clearly understood
for each alternative.

I agree completely, and I see (building) architects making the
same sorts of decisions. As you say, that's really what the
architecture is about. The use you mention at top is just an
"outsiders" casual way of describing something.

I suppose I could argue that, the guy who (presumably after
considering all those important relationships) originally
designed the "Sun Solaris server running an Oracle back-end
accessed by Win2000 PC's over a 1 GB LAN, etc. etc." was
the Architect and the "outsiders" are just referring to his
(or her) work in a manner most people will grok.

My gripe is that this not the case very often. The
so-called "results" are usually presented with no
justification for the choices. In my mind, "why"
is more important than "what."

"We're using XYX *because* ... " is much more
illuminating than "We're using XYZ."

I agree! I only add that selection of those construction
materials *is* part of the analysis and design.

Absolutely! The selection of the construction
materials should be part of the analysis and
design, rather than the selection of construction
materials happening a priori. (With some hopefully
reasonable caveats.)

- If you're mostly a Java (or C or C++ or whatever)
shop, it is pointless (IMO) to choose some other language.
Similarly the choice of database system. (re)Training
your folks in the other language/DBMS will probably have
you miss your dates and lower the overall quality
because of OJT issues.

- On the other hand, if, e.g., you are used to operating
in a stateless client-server (pull) model
but upon analysis of the needs of the customer
you decide that either a stateful connection-based
model, an event driven (push) model, or even
a "batch processing" model (with 5 second batches)
is more appropriate, then this should influence
your choice of the 3PV (3rd party vendor) tools
you use for development.
(The construction materials, so to speak.)

While one can force-fit any of the abovementioned
models (or styles) to emulate any of the others,
one usually has to go through unnecessary gyrations
to do so. Note that within any of these models,
appropriate design principles as you mentioned
in a previous post, e.g. encapsulation, etc.,
must still apply.

The choice of model should also be a factor in the
lower-level designs, at least from a consistency standpoint.
The individual developers (assuming >>1 developer)
should be aware of these higher-level "architectural"
decisions in order to have the whole "system"
be perceived as a coherent whole by the customer.
That is, unless a real need for variation can be
demonstrated, then the higher-level architectural
principles should hold.

[Aside: while I have admitted that UI's are my
weak point when it comes to development, I *do* know
when a UI drives me up a wall. Consider a
UI where some options are presented in a drop-down
menu or menu hierarchy, while some others bring up
a dialog box with radio buttons or check boxes,
while still others bring up something else for you to
navigate through. Any or all of these may work, but
a little bit of consistency can go a long way toward
making the whole thing look like a unified
concept rather than a hodge-podge. That, too,
is "software architecture."]

Sad, but often true.

Agreed. Much too often true. The examples
I've used only really applied to interactions
between components within a "system," e.g.
PC's talking to a back-end server. Now consider
what happens when this "system" has to interact
with other "systems" in order to do it's job.
(Kicking it up yet another notch.)
Should not the same principles apply?

 

[Nick Landsberg]

Cristiano Sadun wrote:

Well, the idea of (software) "architecture" as "nothing more
special than the first level of design" is something I relate to.

Well, I can certainly agree that "architecture" includes the "first
level of design"! But I'd say that first level is pretty special!

Creating something from nothing is (to me) special.

However, this may touch on a difference in perception we have.
See [A] below.

There's also the bit about how a building architect's role is
different than a software architect's role (the latter, at least,
as it's often perceived: someone with deep experience, insights
and instincts in the technical aspects of things. Where the
construction architect has a structural engineering instead to
make things actually work).

If I follow, you're saying the software architect has greater
technical knowledge of the construction of his design than does
the building architect?

I think you might want to speak with a few building architects! (-:

From what I've experienced, they do tend to know a great deal
about the technical requirements and their designs include a
*lot* of the constructive elements (if not all!). (If you look
at the detail drawings of buildings, they often include where to
put the bolts.) Also, building architects use engineering
knowledge to insure their designs will actually work.

[A]
Of course, we may be drawing a line in a different place. When I
talk about the architecture of a building, I *am* talking about the
full design (including construction details), not just some drawings
or models of what it should *look* like.

Hmmm... there is a gray area here. When doing the intitial
models (possibly for presenting them to a customer as
"proof" of concept) the architect has something I will
call "professional intuition/experience" for the sake of this
discussion. For example, one can not expect a 12"
deep "H" section to span 300 feet without intermediate
supports. (Think of a highway overpass.)

Thus the balsa-wood prototype presented to the
client, would either have intermediate supports or would
be scaled to use a girder of appropriate depth.
Even at this stage someone would have estimated
in gross terms what the costs of intermediate
supports would be vs. what the cost of a deeper
girder would be.

At this point, it is not necessary to have designed
the joints between girders, nor whether they are
to be rivetted or welded. That's a "design detail".
That detail, however, *must* be spelled out in the final
plans and specifications.

As an attempt at an analogy for software, let's
presume that you need to support something like
1,000 TPS. (Transactions per second). You
should (intutively?) know whether your server box
either is or is not capable of that. If it is
not, you have some hard decisions to make regarding
either how you use multiple boxes or whether you
invest in a single larger, faster box, or whether
you specify RAID arrays because the bottleneck is
Disk I/O rates.

All of this is before writing a single line of
*production* code, BTW. (Prototyping allowed.)

Nick L.

 

[Chris Sonnack]

Does the word 'grok' really exist, or is it purely an artifact of
Heinleins imagination in "Stranger in a Strange Land"?

AFAIK, it's pure Heinlein.

 

[Chris Sonnack]

Hmmm... there is a gray area here. When doing the intitial
models (possibly for presenting them to a customer as
"proof" of concept) the architect has something I will
call "professional intuition/experience" for the sake of this
discussion. For example, one can not expect a 12"
deep "H" section to span 300 feet without intermediate
supports. (Think of a highway overpass.)

Agreed. Exactly as one wouldn't expect a single box to do
one-million complex transactions per second.

[snip]
At this point, it is not necessary to have designed
the joints between girders, nor whether they are
to be rivetted or welded. That's a "design detail".
That detail, however, *must* be spelled out in the final
plans and specifications.

Agreed again.

And, as you say, a software "model" (in the sense of a proposal)
follows a similar route: overall specificiation based on that
"professional intuition/experience" followed by ever increasing
specifications.

So what was the gray area? We seem on the "same page"! (-:

One interesting difference: building specs follow what we would
call the "waterfall model"--a full spec before construction.
Can you imagine a "spiral model" building construction?

Build the outer shell. Have the customer "try it" and give
feedback. Modify the outer shell, while beginning to rough
out the inner function. Have the customer try it. Improve
the thing. Have the customer try it. Repeat as necessary. (-:

 

[Elspeth Thorne]

Chris Sonnack wrote:

Many of us did! However, I'm not sure I equate *appreciation* of
esthetics with true artistic creativity. Artists create something
from the "whole cloth". Building something from a design--no
matter how elegant, esthetic or pleasing--isn't art (to me!).

Ah, but coming up with the design - that's an art. Or black magic, depending on
which software professional you talk to.

Elspeth.

 

[Chris Sonnack]

Ah, but coming up with the design - that's an art. Or black magic,
depending on which software professional you talk to.

Yes, indeed!

 

[Alan Gauld]

esthetics with true artistic creativity. Artists create something
Is that true? Most great works of art are the result of multiple
sketches(*), clay models, etc. That sounds a lot like iterative
design to me. It may not be a formal specification but its
certainly not jumping in to the finished article from scratch
either... And many of the classical "artists" were also the
engineers and architects of their day - consider Da Vinci,
Donatello etc

(*)And those sketches and models can become valuable artifacts in
their own right...

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Chris Sonnack]

Is that true?

Yes. (-:

Most great works of art are the result of multiple sketches(*),
clay models, etc. That sounds a lot like iterative design to me.

(There's no reason to exclude most art by referring to "great"
works, I think.)

This is true, but note that you still use the term "design". To
design something is to create something new. All that iterative
process *starts* with a vision of a "new thing", and that is what
I mean by creating from the whole cloth.

It may not be a formal specification but its certainly not
jumping in to the finished article from scratch either...

Absolutely. Although some art does spring largely whole from
nothing. I know of a couple good (and popular) authors who
write their storys largely without prior plotting and planning.
They come up with a basic idea and throw their characters into
it and "see what happens". And I've seen visual artists create
finished sketches and paintings from scratch. I can name many
cases where art does "leap into life whole".

In any event, I think there is a continuum from "pure" or "high"
art (think: Mona Lisa, Vivaldi, etc.) through "commercial" art,
through building architecture and ending at engineering design.

In all cases, the artist/designer creates a New Thing from scratch.
The qualifier of the continuum is.... well, let me explain what I
think art is:

Art is the preception and re-expression of reality
and exerience on the part of a mind.

Artists--who create art for art sake--are those with a drive or
a need to indulge in that re-expression of their experiences and
perceptions.

Commercial art may be informed by the artist's soul, but it is
bespoke and created within defined limits (i.e. a spec). The more
you move towards the design engineering end of the continuum, the
less the artist's/designer's personal expression obtains.

And many of the classical "artists" were also the engineers and
architects of their day - consider Da Vinci, Donatello etc

Sure. Remember that, in their day, cross-training was very, very
common among intelligent, seeking minds. Even today we have
artists who are also technicians or engineers. Peter Gabriel
springs to mind, for example.