Luke Hohmann talks with Bill Venners about mapping software architecture to human needs, choosing languages for social reasons, and selecting the appropriate architectural granularity.

Read this Artima.com interview with the author of Beyond Software Architecture:

http://www.artima.com/intv/balance.html

What do you think of Luke's comments?

" ...every individual writes code based on the context of the structure that they hold inside their head, their own concept of the architecture. If this differs you're going to have problems."

Haven't you got to assume you're going to have these problems. You may not have these problems one week but then you have them the next. And if they differ, who is right and who is wrong?

The best you can hope for is that people maintain an understanding of the context of their own domain of work.

Where does this understanding of the architecture come from? Seems the only place it can be derived from is the system itself. The system should be capable of visualising it's own architecture.

My thinking, which may be outdated, is that the system should be able to illustrate itself in terms of its architecture which can be understood and appreciated by users inside and outside the development community.

Self-illustrating systems? A subject I've been wasting my time on for the last few years, see:

http://www.jpitten.btinternet.co.uk/

Marvelous thoughts. You have a very pragmatic
view of the world, born in the trenches. And
your views are eloquently expressed.

"Language as a social choice" is particularly
interesting. For a manager to choose a language
on that basis only makes sense. It's one of the
important requirements for serious production,
actually -- will there be a pool of programmers
available to work on it, downstream?

As a technophile, I admit that I often chosen
a personal project as much to learn a new language
as for any other reason -- because doing something
real takes you into the nuances of the language
and drives you through the learning curve.

But when I'm making a technical recommendation
for a project, it is generally based on the
merits of the language, and the ease of using
it for the task at hand.

Your Perl scripts example was a perfect example
of "social choice gone wrong" -- because the
choice was made for the wrong reasons (social,
rather than technical).

So my take on things is that:
a) Managers have a clear need to make social
choices, but they also need to factor in
technical recommendations
b) Technicians need small projects to explore
languages so they can make recommendations
c) The recommendations they make for large
projects need to be based on technical merit

The author is explicitly writing down the things that 1st year programmers know so that 1st year-out-of-school managers can keep up.

Another way of looking at it is dealing with churning the toolset, going from C to C++ to Java to J2EE to .NET, for example. As the OS and the development environment expand to fill the gigabytes of available space, the support system gets so complex that it doesn't hang around long enough for everybody to learn it before the development system gets replaced. Nowadays nearly all the applications that run on a computer are dwarfed by the huge OS's, runtimes, and development environments. I swear, it used to be the other way around.

Although Hohmann didn't explicitly mention this, I infer from his reasoning that this is partly why reusable code and object oriented code have only been partially successful. That is, using an inhouse library to manage sockets and threads is great, but that doesn't make for a particularly impressive resume. Hiring managers unfortunately, seem to want knowledge of the socket and thread api, and don't care that the candidate was smart enough to learn the inhouse library.

Designing and writing the inhouse library, however, looks quite good.

Pretty interesting

http://www.science-tips.org