" ...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:

Marvelous thoughts. You have a very pragmaticview of the world, born in the trenches. Andyour views are eloquently expressed.

"Language as a social choice" is particularlyinteresting. For a manager to choose a languageon that basis only makes sense. It's one of theimportant requirements for serious production,actually -- will there be a pool of programmersavailable to work on it, downstream?

As a technophile, I admit that I often chosena personal project as much to learn a new languageas for any other reason -- because doing somethingreal takes you into the nuances of the languageand 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 usingit for the task at hand.

Your Perl scripts example was a perfect exampleof "social choice gone wrong" -- because thechoice 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.