«

On 09/26/11 01:00 AM, Rui Maciel wrote:
> Ian Collins wrote:
>
>> On 09/25/11 09:53 AM, Rui Maciel wrote:
>>>
>>> There are a lot of engineers (mainly mechanical, but also a fair share of
>>> aeronautical, civil and others) who spend their careers designing,
>>> testing and tweaking engines, specific engine parts or associated
>>> components.
>>
>> So the Electronics Engineers and programmers who design, test and tweak
>> the control system that make those engines work are just lackeys?
>
> It really depends on the level of competence and responsibility which
> society requires from those who wish to do a specific job.

Quite. Society requires a ABS computer to function to the same standard
as the mechanical components in a vehicle's brakes. Society requires
the flight control computers to be as reliable as the aircraft's engines.

Very few modern engineering projects are single discipline. They are
built from a diverse range of components, both mechanical, electronic
and software. All of these are critical to the operation of the
product. All of these have to be built to the same high standards
following the same strict engineering practices.

> For example, do
> you believe that someone who manages to develop spreadsheets with
> conditional statements is, due to that, an engineer? What about someone who
> manages to put together a shell script/batch file? What about putting
> together a "hello world" program in visual basic? Or developing a tic-tac-
> toe program in Python? Or developing a text editor in C++? Does the
> ability to perform any of those tasks, on it's own, bestows onto anyone the
> right to call what he does as being engineering? Do you consider someone
> who managed to learn how to write some C++ code in his spare time to be an
> engineer?

Every field of engineering has shed tinkerers, we'd probably still be
leaving in trees without them.

Do you consider James Dyson to be an engineer? How about Frank Whittle?

> The thing is, the requirements for someone to be considered an engineer are
> similar in nature to the requirements that society imposes on who is and who
> is not a physician or a surgeon or a dentist or a lawyer. Those titles are
> reserved to those among us which are granted the right to perform services
> which require a high level of training, competence and responsibility. If
> society doesn't require that a task should be reserved to a carefully
> selected group of people in order to safeguard society's best interests then
> no such demands are put in place.

Society knows very little about the individuals behind most engineering
projects. Society puts it's trust in the companies who produce the
products to employ suitably qualified staff. Unlike medical or legal
practitioners, it is the manufacturer who ends up in the dock, not the
individual engineer.

--
Ian Collins

On Sep 25, 2:15*pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 09/26/11 01:00 AM, Rui Maciel wrote:
>
> > Ian Collins wrote:
>
> >> On 09/25/11 09:53 AM, Rui Maciel wrote:
>
> >>> There are a lot of engineers (mainly mechanical, but also a fair share of
> >>> aeronautical, civil and others) who spend their careers designing,
> >>> testing and tweaking engines, specific engine parts or associated
> >>> components.
>
> >> So the Electronics Engineers and programmers who design, test and tweak
> >> the control system that make those engines work are just lackeys?
>
> > It really depends on the level of competence and responsibility which
> > society requires from those who wish to do a specific job.
>
> Quite. *Society requires a ABS computer to function to the same standard
> as the mechanical components in a vehicle's brakes. *Society requires
> the flight control computers to be as reliable as the aircraft's engines.
>
> Very few modern engineering projects are single discipline. *They are
> built from a diverse range of components, both mechanical, electronic
> and software. *All of these are critical to the operation of the
> product. *All of these have to be built to the same high standards
> following the same strict engineering practices.
>
> > For example, do
> > you believe that someone who manages to develop spreadsheets with
> > conditional statements is, due to that, an engineer? *What about someone who
> > manages to put together a shell script/batch file? *What about putting
> > together a "hello world" program in visual basic? *Or developing a tic-tac-
> > toe program in Python? *Or developing a text editor in C++? *Does the
> > ability to perform any of those tasks, on it's own, bestows onto anyonethe
> > right to call what he does as being engineering? *Do you consider someone
> > who managed to learn how to write some C++ code in his spare time to bean
> > engineer?
>
> Every field of engineering has shed tinkerers, we'd probably still be
> leaving in trees without them.
>
> Do you consider James Dyson to be an engineer? How about Frank Whittle?
>
> > The thing is, the requirements for someone to be considered an engineerare
> > similar in nature to the requirements that society imposes on who is and who
> > is not a physician or a surgeon or a dentist or a lawyer. *Those titles are
> > reserved to those among us which are granted the right to perform services
> > which require a high level of training, competence and responsibility. *If
> > society doesn't require that a task should be reserved to a carefully
> > selected group of people in order to safeguard society's best intereststhen
> > no such demands are put in place.
>
> Society knows very little about the individuals behind most engineering
> projects. *Society puts it's trust in the companies who produce the
> products to employ suitably qualified staff. *Unlike medical or legal
> practitioners, it is the manufacturer who ends up in the dock, not the
> individual engineer.
>

The national motto of the United States is:
In G-d we trust. The motto was part of our
becoming a great nation.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net

On 09/26/11 05:26 PM, Ebenezer wrote:
>
> The national motto of the United States is:
> In G-d we trust. The motto was part of our
> becoming a great nation.

With a withering debt to match!

No sound engineering practices there...

--
Ian Collins

Ebenezer <> writes:
> The national motto of the United States is: In G-d we trust.

When are they gonna get rid of that, anyway?

"E Pluribus Unum" is _vastly_ cooler, more historically resonant, and
really, more accurate.

> The motto was part of our becoming a great nation.

Hmm, not really. The U.S. has only had an official motto since the
'50s, and lets face it, the U.S. hasn't exactly been a shining start
since then...

-Miles

--
Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a
man's head.

On Sep 25, 7:28*pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> Nick Keighley wrote:
> > I think you'll find the emdedded people get held liable. If the brakes
> > on the car don't work then I suspect a defence of "we replaced
> > mechanical linkage with fly-by-wire consequently it was software that
> > caused the failure hence we cannot be held liable" would not work.
>
> And if an electrician screws up and someone gets electrocuted he will also
> be held liable for his screwup. *Yet, that doesn't mean that an electrician
> is an engineer.
>
> Just because a given task is technical in nature it doesn't mean it is
> engineering, and software development is clearly one of those cases. *

argument by repetition

> Similarly, it is also not architecture. *It is what it is.
>
> > The world is not a desktop...
>
> ...nor it is supposed to be. *A software developer doesn't suddenly become
> an engineer if he targets a platform other than a desktop.

but the product is liable to be judged to a higher standard if its
controlling brakes rather than a word processor (though we'd like a
word processors to work as well...)

In article <4e7ce154$0$16762$>,
Rui Maciel <> wrote:
>
>Stating that an occupation isn't engineering is not denigrating somebody or
>their work. It can only be seen as a way to denigrate someone if that
>person happens to desperately want a fancy title to feel better about
>themselves, and this is just wrong. There is a reason why society felt the
>need to punish those who misappropriated professional titles.
>
>The odd thing about your comment is that in some circles, particularly hard
>science and math, engineering is looked down on. I guess one man's trash is
>another man's treasure.

When I was studying Electrical Engineering at University, some of our
courses were shared with the Physics department and the Physic
Engineering department. (or is it Engineering Physics? "Genie
Physique" in French). The difference between the three courses (in a
jokey biased way) was said to be:

Physics: It doesn't work but they know why.
Physic Engineering: It doesn't work and they don't know why.
Electrical Engineering: It works but they don't know why.

I guess that was meant to denigrate Physic Engineering. But
to this day, I am still not sure if Physics or Electrical Engineering
came out the worse of the other two

Yannick

In article <4e7e4339$0$16765$>,
Rui Maciel <> wrote:
>
>Which mailing list are we talking about? Are you referring to
>comp.lang.c++? Because claiming that this newsgroup is "dedicated to
>engineering", or even insinuating that writing C++ code is engineering,
>would be an even more glaring mistake.
>
>
>> or
>> maybe you are right that software makers should be responsible
>> for bugs, I've heard of some EU efforts towards such laws, which
>> are meant to protect consumers; they are not meant to result
>> in criminal punishments though.
>
>I haven't made such a claim, nor I believe I will ever do, mainly because it
>goes against society's best interests to increase the costs associated with
>developing software. Society doesn't grind to a halt, nor does it suffer
>any relevant losses, if a text editor segfaults or if an OS throws a blue
>screen of death.

This statement is rather confused. You give two examples of what you
consider software bugs with minor consequences. However, in the
modern world, the consequences of a bug in software have to potential
to dwarf almost any other traditional engineering discipline mistakes.

Society wouldn't grind to a halt either if a construction project of a
local shopping mall gets delayed because the Civil Engineer didn't do
his computations correctly, a roof collapse and they need to demolish
a large part of the building in order to restart on solid fundations.

On the other hand, society would pretty much grind to a halt if the
software that is used to compute peoples income tax starts misbehaving
and starts sending a large amount of overdue tax claims all around the
country.

Society would pretty much grind to a halt if a bug in fly-by-wire or
ILS caused a few aircrafts to crash.

Society could literally grind to a halt if the traffic control system
software of a major city started misbehaving.

So certainly, the difference between engineering and not engineering
can't be based solely on the potential consequences of a mistake.

Yannick

Nick Keighley wrote:

> On Sep 25, 7:28 pm, Rui Maciel <rui.mac...@gmail.com> wrote:
>> Nick Keighley wrote:
>> > I think you'll find the emdedded people get held liable. If the brakes
>> > on the car don't work then I suspect a defence of "we replaced
>> > mechanical linkage with fly-by-wire consequently it was software that
>> > caused the failure hence we cannot be held liable" would not work.
>>
>> And if an electrician screws up and someone gets electrocuted he will
>> also be held liable for his screwup. Yet, that doesn't mean that an
>> electrician is an engineer.
>>
>> Just because a given task is technical in nature it doesn't mean it is
>> engineering, and software development is clearly one of those cases.
>
> argument by repetition

And it's a shame it is necessary to repeat it. This has been covered
before.


>> Similarly, it is also not architecture. It is what it is.
>>
>> > The world is not a desktop...
>>
>> ...nor it is supposed to be. A software developer doesn't suddenly
>> become an engineer if he targets a platform other than a desktop.
>
> but the product is liable to be judged to a higher standard if its
> controlling brakes rather than a word processor (though we'd like a
> word processors to work as well...)

Again, the contribution to the design and production of a product/service
whose shortcomings may lead the ones responsible to be held liable does make
an engineer out of everyone who has been involved in that project. There
are plenty of other technical fields who rely on technicians to develop
important parts of a project, including in the design stage, and yet there
is still no reason to label them with titles such as engineer or architect.
So, why would this be any different with writing software?


Rui Maciel

On 9/23/2011 1:36 AM, DeMarcus wrote:
> On 09/22/2011 09:23 PM, BGB wrote:
>> On 9/22/2011 11:51 AM, red floyd wrote:
>>> On 9/22/2011 2:25 AM, DeMarcus wrote:
>>>> Hi,
>>>>
>>>> We all do software development. Some even do software architecture. But
>>>> is there a common name for all the things around software development?
>>>>
>>>> With things around software development I mean for instance:
>>>>
>>>> * Version controlling, e.g. cvs, svn, git, etc.
>>>> * Documentation, e.g. Doxygen, etc.
>>>> * Bug- and issue tracking, e.g. Bugzilla, Jira, etc.
>>>> * Unit testing, e.g. TDD, etc.
>>>> * Build systems, e.g. TeamCity, etc.
>>>>
>>>>
>>>> Is there a common name for all that kind of work above? I couldn't find
>>>> any on the net so I just invented two alternatives to start with:
>>>>
>>>> Development Groundwork
>>>> or
>>>> Development Support
>>>>
>>>>
>>>> Or is there already a common name?
>>>
>>> Software Engineering
>>>
>>
>> yes, although often Software Engineer is also used as a glorified term
>> for a Programmer (which doesn't necessarily imply doing things like
>> documentation or writing unit tests).
>>
>>
>> also fairly common is the "code and go" strategy, where one writes code,
>> basically verifies that it about works (via manual testing), and calls
>> it "good enough" until bugs or crashes start making an issue (then one
>> goes and debugs them).
>>
>> if there are other people around, then usually they will be responsible
>> for doing this other stuff (the documentation person documents it, and
>> the tester tests it and reports bugs).
>>
>> or, otherwise, it is a single-person project, where one has to
>> prioritize where they will invest their time, and where having good
>> documentation may be a much lower priority than "getting it done" or
>> "getting the next round of features added", ...
>>
>> a Programmer may differ some from a Coder, where the former is
>> generally/often given the ability to think and write code independently
>> (they decide the best way to implement the requirements, ...), whereas a
>> Coder usually has all designs/specifications/... handed down "from
>> above", say: "here is a class diagram, list of functions and methods,
>> and behavioral descriptions. now go implement it." (in this case, the
>> Software Engineer is generally the person who writes up the stuff that
>> the coder goes and implements).
>>
>> the differences can be subtle, and often the term "programmer" is used
>> in the same sense as "coder" above.
>>
>>
>> but, used in-sense, Software Engineer implies doing lots of design and
>> trying to make everything proper and similar (like, the whole "engineer"
>> part).
>>
>>
>> however, in my case, I mostly just claim to be a programmer.
>>
>> although what I do does have some overlap with what would be considered
>> a software-engineers' area (being a lone developer, I deal with pretty
>> much everything), the primary goal remains that of getting things
>> implemented and working, ideally in a timely manner (and usually getting
>> things working "now" is a much higher priority than any future
>> maintainability).
>>
>>
>> or such...
>
> I like your definitions. How about this?
>
> * Software Architect - Designs frameworks, communication and
> dependencies in applications and between applications.
>
> * Software Engineer - Designs specific modules in an application, often
> specialized in some field like mathematics, protocols, or certain domain
> specific knowledge.
>
> * Coder - Implements specifications. Could be a person directly from
> school.
>

fair enough, however often the roles of architects and engineers are not
often so clearly separated, or in smaller projects, there may not be
much separation between the people doing the design and the people doing
the programming.

a lot depends likely on the size of the project and the size of the
team, as well as potentially on the particular "development culture" in
play, ...


>
> / Daniel

On Thu, 2011-09-22, DeMarcus wrote:
> On 09/22/2011 03:12 PM, none Yannick Tremblay wrote:
....
>> I've seen Configuration Management used for Version Controlling and
>> sometimes build system.
>> http://en.wikipedia.org/wiki/Configu...ion_management
>>
>
> True, however, Configuration Management focus on a /part/ of, let's call
> it Development Support. Also, Configuration Management usually only
> involves a few people per team.

I repeat myself, but I have to disagree again.

There may be a guy called "the CM" and he may even be useful --
keeping track of large-scale things and providing advice. But
if I as a programmer pretend that CM is someone else's problem,
I'm not doing my job. I need to make the work I do blend in well with
the work others do; I need to be able to deliver feature FOO without
also delivering the incomplete feature BAR. And so on.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .