Re: Is the Writing on the Wall for Ada?

[aek@vib.usr.pu.ru (Alexander Kopilovitch)]

Robert I. Eachus wrote:

>But with true Software Engineering, which is not about programming,

Being a programmer, and not a software engineer, I'm very pleased to see this
clear distinction. During about 10 years I often tried to explain for various
people and in various situations that a programmer and a software engineer
aren't the same, that these must have different (although with substantial
intersection) skills and different spirit... different priorities and different
goals. Certainly they are neighbours (say, like a physicist and a chemist -;) ,
and they may be good neighbours and somehow understand and help each other.
They even can emulate each other, but almost always with some degradation in
rank (there are exceptions, though -:) . Only recently (perhaps about 2 years)
I began to meet (occasionally) similar viewpoint.

> as far as I am concerned, it is possible for someone to become a 
> master of software engineering without the gift for teaching.  But it is 
> tough, because teaching is really one of the key skills needed for the 
> job.  Part of what a software engineer--as opposed to a programmer with 
> the same title--does is develop a style which is appropriate for the 
> type of job being done, and then teaching that style to the rest of the 
> team.  I am not talking about indentation, variable naming and the like. 
> That is just detail.  I am talking about real software architecture, 
> designing a system which will satisfy the requirements and also be 
> something that humans who maintain or use the system will enjoy. (Enjoy 
> is a much higher standard than "be comfortable with."  But it is one of 
> the signs of a good system architecture.

Yes, I think that developing of a style and teaching that style the team is
very important for software engineering. The style creates a medium (and/or
"carrier wave") in which internal (within the team) informational protocols
emerge and exist. And which is especially important for maintenance, significant
parts of those mediums and protocols are recoverable afterwards.

> Now this doesn't say that someone in India or Pakistan can't develop a 
> style which people in the United States will be comfortable with.  It is 
> just that the inevitable culture clash between the people on the project 
> in the US and the foreign development team will create additional 
> problems.  (And if the only people on the project in the US are 
> managers, that clash will probably cause insurmountable problems.)  So 
> what does work, and I have seen it work, is for a software engineer from 
> India or whereever to become Americanized (or Europeanized) and serve as 
> a buffer and interface between the two part of the project.

Just for coloring this your statement (which is certainly true) here is a
funny story: an old friend of mine, a true software engineer (despite his
pure mathematical education), who moved to USA 12 years ago and now work for
one of so-called "giants" (which naturally have divisions in India), once wrote
me (I translate from Russian): "Sometimes I receive a mail from one of those
Indians, and after brief reading my first thought is to reply him: guy, first
learn to cut your nails, and only after that try to approach a programming...
but then I recall you, and reread the mail - and discover that the guy is not
so stupid and dirty, in fact he wrote something quite reasonable."



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia