Who gets higher salary a Java Programmer or a C++ Programmer?

J

James Kanze

One of my bosses expounds the same basic idea. The strategy is
that we compete with the outsourcers on a cost-per-project
basis. We can't compete on cost-per-head, because we live in
London (or even worse, live in the UK and commute to London),
not Bangalore, and we like to work 40-hour weeks and earn
enough to live comfortable lives [1]. However, if we're good
enough - skilled, experienced, and well-organised enough - we
can deliver a project with a fraction of the man-hours of an
outsourcing shop, and thus be competitive on total cost.

Normally, cost isn't the only issue. I've worked on projects
where part of the work was outsourced to Bangalore. What is
clear is that 1) it's cheaper, and 2) the competence of the
people involved was at least as good (and often better) than the
people we had on site (in Germany). On the other hand,
communication was an enormous problem.

If your customer can specify exactly what he wants, with no
ambiguity, and he knows how to vet his supplier, there's no way
you can compete with Bangalore. You raise a number of points,
but all of the technical once (your team are gurus, etc.) are
easily matched in Bangalore. Don't underestimate them; they're
good. On the other hand, it's rarely the case that the customer
knows exactly what he wants, and being on hand to discuss
various possible changes in the requirements or specifications
can far outweigh any price advantage.
 
J

James Kanze

I have a speech about that.
We are in the middle of a revolution in software development.

The revolution in software development took place long ago (by
the usual measures in this field). Software engineering is a
mature discipline today, even if there are still a lot of
retrograde shops which don't understand this.
Today, with few exceptions, software development is FAR more
art than engineering, and most of us are "software artists"
instead of "software engineers". Programs are carefully
hand-crafted one line at a time, like an amateur building a
bridge out of balsa wood, and not engineered, like an
engineering firm building a highway bridge.

And that is simply false. If a company is doing that, their
software costs far too much.
If we are ever to build reliable large software systems,
software development needs to transition to a true engineering
discipline. The tools are on their way to being able to
enable that transition, but they aren't there yet.

We build reliable large software systems today. At least, I've
worked in companies that do. If the software I've worked on
wasn't reliable, your phones wouldn't work, you wouldn't have
reliable electricity, the brakes on your car wouldn't work
(actually, I worked on train brakes, not car brakes, but the
principle is the same), etc., etc.
The tools that my partner uses to create chips are much better
suited to "engineering" than the tools I use to create
software.

The tools your partner uses to create chips are run by software.
Compare a Pentium IV processor to Windows, for example. I've
had many debates, usually under the influence of intoxicants,
over which one of those is more "complicated". I would argue
that Windows is much less reliable than the Pentium IV,
because the tools aren't as good.

Or they haven't been used correctly (or at all). Perhaps the
management at Microsoft thinks like you do with respect to
software engineering, rather than informing themselves of the
what can really be done. (Or perhaps they're just stuck with a
lot of legacy code, and fear that a total rewrite using modern
software engineering techniques would be too expensive.)

Note that just because some firms don't practice software
engineering (and Microsoft is far from alone in this) doesn't
mean that it doesn't exist.
When programming does transition to an engineering discipline,
it will be a much better thing for the world at large, but it
won't be nearly as much fun.

It depends on what you consider "fun". There is a certain
personal satisfact to be had in knowing that you've just
delivered a program which actually works.
 
L

LR

James said:
Software engineering

I am still wondering what the definition of this is.

And that is simply false. If a company is doing that, their
software costs far too much.

Could you please expand on this, how does using software tools change
software development to an engineering discipline?

There is a certain
personal satisfact to be had in knowing that you've just
delivered a program which actually works.

Do the programs provably work? To the same extent that an engineer could
"prove" that the bridge they designed will work? What kinds of metrics
are used? Does software have a stress point beyond which it will
deform, like the metal in the bridge will?

LR
 
L

Lew

Tim said:
I have a hard time using the word "expert" anywhere around a web site that
thinks the word "doctor" is actually spelled "docter".

I won't be going back to GetClub.com.

I am so disappointed in Sanny for spamming this group, and right in the middle
of an interesting discussion, too. He's starting to seem quite plonk-worthy.

I am not surprised that the quality of the spammed-for site should suck so
badly. That is to be expected.

Tsk, tsk, Sanny.
 
L

Lew

LR said:
Shouldn't that rather be t'other way round? Isn't it that people who
understand that software isn't, and cannot be an engineering discipline,
inspire the confidence that comes from having an appreciation of one's
tools?

You are begging the question.

And wrong. Software development can be, and is, an engineering discipline.
 
P

Puppet_Sock

How much max salary per Annum I can get If I become a C++ Expert.
and How much max salary per Annum I can get If I become a Java Expert.

If all you care about is maxing your salary, you
should learn COBOL. There are millions of lines of
old business apps, payroll, accounting, etc., that
were written in COBOL. Because many people don't
want to admit to being proficient at COBOL, the
billable rate for COBOL developers is huge.
Socks
 
P

Puppet_Sock

What language should I master. I just want to know who gets higher
salary a Java Programmer or a C++ Programmer?

Seriously, this is backwards.

Learn the one that is going to get you a job today.
Or this week or this month or whatever.

Master the concepts of good software design and
development. That is, look at what is good design,
what is a good idiom, how do you approach a software
task so as to get to a good product at the end.

Such things are, to some degree, influenced by the
language. Good design in Java is not identical to
good design in C++. But also, to some degree, the
idea of good design is transferable to other languages.
For example, one generic idea is to manage complexity.
There are ways to localize and hide complexity, so as
to make the largest chunk of information a coder has
to understand at any given time as small as possible.
There are ways to make the scope of various items in
the code as short as possible, so as to minimize the
impact of changes to the code. There are ways to code
such that changes are easy to make when the spec is
updated, changes are easy to see to be correct, easy
to test, easy to document, etc. And so on.

A good book on this topic is
_Code Complete: A Practical Handbook of Software
Construction_ by Steve McConnell (2nd Edition).
But don't let that be the only book you read on
the topic. Depending on the specific area of work
you select (or get a job in) then there are lots of
other books to make that task easier. For example, if
you get into scientific or numerical work, you want
one set of books. If you do communications, another.
If you do user interface, another. Security, another.
And so on.

If you learn good software development methods, then
you will have a better chance of earning the big bucks
regardless of language.
Socks
 
L

LR

Lew said:
You are begging the question.

No, I contradicting you.
And wrong. Software development can be, and is, an engineering discipline.

No, I'm right. But please feel free to explain how software development
can be an engineering discipline. TIA.

LR
 
C

courpron

{...]
Do the programs provably work? To the same extent that an engineer could
"prove" that the bridge they designed will work?  

There is a whole branch of computer science that is dedicated to
"program provability". In the practical world, the theory gave rise to
what is called "design by contract", by which you define formally the
specifications of your program with pre/postconditions, invariants,
etc. You can mathematically prove that your program will work by those
means. This is used in any sensible environment that needs absolutely
reliable softwares.

Alexandre Courpron.
 
T

Tom Anderson

When I was young, or at least younger than I am now, I was taught that
engineering is the application of scientific principles. This makes me
curious to know, what scientific principles are being applied in the
development of software?

Exactly. The making of software is not, and will never be, engineering.

The simple reason for this is that software is not analytically tractable.
There's nothing that is to software as Newton's laws, or all the other
physical discoveries of the nineteenth century, are to mechanical
engineering. And because software is manifestly vastly nonlinear, it's
quite clear that, barring a titanic theoretical breakthrough, there never
will be.

With a bridge, i can build a system of linear equations that describes it,
not perfectly, but to a high degree of accuracy, and i can put those into
a computer and solve them, and show that the bridge won't fall down when
trains run across it. My calculations are only approximations, although
pretty accurate ones, but i can add a safety factor to cover that. I can
say with a great deal of confidence that the bridge as designed will work.

There's no analogue of this in software. There's no useful description of
a system any simpler than the system itself. I can draw UML diagrams or
write prototype code, or do a high-level sketch in some kind of formal
language, and i *might* be able to verify that those do the right thing,
but there's no way to get from there to the real thing. There's no
analogue to the idea of the model being a close approximation - one
character out of place somewhere in the implementation can completely
change the behaviour of the whole system.

Nor can you apply analysis of this kind to the actual program, which is
actually a closer analogue to the bridge engineer's analysis [1].

There are brave and optimistic people who have tried, and are trying, to
do something about this - to find ways of proving things about programs,
or of writing programs about which things can be proven, so that we can
look at a system and give cast-iron guarantees - mathematical proofs, even
stronger than the bridge engineer's calculations - that the thing will
work as specified. Sadly, the resounding finding is that it's just not
practical to give useful guarantees for useful programs. Maybe that will
change, but there are no signs of that so far.

Still, i call myself a 'software engineer' because it sounds more
high-status than 'programmer', and i go to a lot of parties with lawyers
and academics and the like.

tom

[1] Since the finished source code is a design, not a product - see:

http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign
 
T

Tom Anderson

The actual example code didn't leak, in any sense of the word. It
corresponded to an established and widely used pattern.

Actually, on looking at the code closer, I think it is a leak.

*facepalm*

Thanks for taking the time to actually read and understand the example. If
i may be so bold as to make a suggestion, maybe do that a little earlier
in the thread next time?

tom
 
T

Tom Anderson

One of my bosses expounds the same basic idea. The strategy is
that we compete with the outsourcers on a cost-per-project
basis. We can't compete on cost-per-head, because we live in
London (or even worse, live in the UK and commute to London),
not Bangalore, and we like to work 40-hour weeks and earn
enough to live comfortable lives [1]. However, if we're good
enough - skilled, experienced, and well-organised enough - we
can deliver a project with a fraction of the man-hours of an
outsourcing shop, and thus be competitive on total cost.

Normally, cost isn't the only issue. I've worked on projects where part
of the work was outsourced to Bangalore. What is clear is that 1) it's
cheaper, and 2) the competence of the people involved was at least as
good (and often better) than the people we had on site (in Germany).
On the other hand, communication was an enormous problem.

If your customer can specify exactly what he wants, with no ambiguity,
and he knows how to vet his supplier, there's no way you can compete
with Bangalore. You raise a number of points, but all of the technical
once (your team are gurus, etc.) are easily matched in Bangalore.
Don't underestimate them; they're good.

Oh, absolutely!

But i'm still skeptical about them being matched. There are plenty of
people in the US and European software industries with 20-30 years, or
more, of experience in their fields. Bangalore's software industry only
took off in the last 10-15 years, so it just hasn't built up a depth of
maturity and experience yet. Equally, of course, it isn't laden with a
deadweight of old guys with obsolete knowledge!

Either way, another 10-15 years from now, things may look very different.
On the other hand, it's rarely the case that the customer knows exactly
what he wants, and being on hand to discuss various possible changes in
the requirements or specifications can far outweigh any price advantage.

Most of our contact with the client consists of emails and phone calls.
Once every few weeks, a couple of people fly out to their offices (which
are in a nearby country). A Bangalore-based team would have a longer plane
trip, but what's to stop them having just as much contact with the client
as us? Is it just a language thing?

We've got a contract coming over the horizon where the client is in the
Middle East. That puts the Bangaloreans closer than us, and nobbles the
lanuguage edge. How about then?

tom
 
T

Tom Anderson

There is a whole branch of computer science that is dedicated to
"program provability". In the practical world, the theory gave rise to
what is called "design by contract", by which you define formally the
specifications of your program with pre/postconditions, invariants, etc.
You can mathematically prove that your program will work by those means.
This is used in any sensible environment that needs absolutely reliable
softwares.

Name three.

If a shop does this - uses those methods to prove that their software
works - then i'm happy to call them software engineers. Ecstatic, in fact
- it's a great and wonderful achievement.

But i believe that the number of such shops is vanishingly small, and
concentrated in a few sectors where the cost is worth it - real-time
control, telecoms, aerospace, defence, medical devices. It's not a
technique that is used for the common bulk of software - desktop apps, web
apps, even operating systems. Furthermore, i don't believe it can be,
because such systems tend to be complex enough that the cost of proving
correctness would be so astronomical that it wouldn't be economical.

tom
 
L

Lars Enderin

I am surprised that Lew hasn't castigated you for writing I in lower
case. How come you're working in Lithuania, by the way?
 
L

Lew

I am surprised that Lew hasn't castigated you for writing I in lower
case.

Nice rhetorical trick. You get to make a grammatical comment but
foist the blame for it off on someone else.
 
L

Lars Enderin

Lew skrev:
Nice rhetorical trick. You get to make a grammatical comment but
foist the blame for it off on someone else.

Sorry. Actually, I meant to write a private comment by mail, but I was
careless. Maybe that would have been equally bad, though?

(I wonder when Google Groups is going to handle signature delimiters "--
" correctly?)
 
C

courpron

Name three.

You already named more later in your message. The use of design by
contract is not reserved to those few sectors. It is mandatory in
those sectors, but is sometimes attractive to other domains because it
removes the need to spend days, weeks, months in the testing phase of
the software development cycle.
If a shop does this - uses those methods to prove that their software
works - then i'm happy to call them software engineers. Ecstatic, in fact
- it's a great and wonderful achievement.

But i believe that the number of such shops is vanishingly small

I don't have the numbers and you don't have them either. In
particular, I wouldn't use the adverb "vanishingly". Furthermore, any
software developper that adopts a defensive programming approach and
uses assertions as pre/postconditions starts to be on the path of DbC.
Such programmers can develop reliable components because of sufficient
defensive programming techniques.
, and
concentrated in a few sectors where the cost is worth it - real-time
control, telecoms, aerospace, defence, medical devices. It's not a
technique that is used for the common bulk of software - desktop apps, web
apps, even operating systems. Furthermore, i don't believe it can be,
because such systems tend to be complex enough that the cost of proving
correctness would be so astronomical that it wouldn't be economical.

If you want to "prove" by DbC a large, existing software, then yes, it
can be costy. If you start a project and use DbC from the beginning of
the development cycle, you can actually make savings because of the
testing phase removal/reduction I mentioned earlier.

Alexandre Courpron.
 
M

Martin Gregorie

But i believe that the number of such shops is vanishingly small, and
concentrated in a few sectors where the cost is worth it - real-time
control, telecoms, aerospace, defence, medical devices.
Substitute 'industrial/nuclear process control' for telecoms and I'd
agree: this substitution assumes that your 'real-time' means vehicle and
machine control.

I remain to be convinced that telecoms code is particularly robust.
 
J

James Kanze

[...]
Oh, absolutely!
But i'm still skeptical about them being matched. There are
plenty of people in the US and European software industries
with 20-30 years, or more, of experience in their fields.
Bangalore's software industry only took off in the last 10-15
years, so it just hasn't built up a depth of maturity and
experience yet. Equally, of course, it isn't laden with a
deadweight of old guys with obsolete knowledge!

All I can say for sure is that the people we were working with
were very competent. More so than the people we could find in
Germany at the time---it's nice to know that there are plenty of
people with 20-30 years experience, but if they aren't on the
job market, it doesn't help.

And of course, some people will not be competent no matter how
much experience, and most will be competent after a lot less
than 20-30 years. The first five years make a big difference,
but if I judge from my own case, most of what I learned more
than five years ago it irrelevant today.
Most of our contact with the client consists of emails and
phone calls. Once every few weeks, a couple of people fly out
to their offices (which are in a nearby country). A
Bangalore-based team would have a longer plane trip, but
what's to stop them having just as much contact with the
client as us? Is it just a language thing?

If contact only once every few weeks is sufficient, then they
likely can do just as good a job for less. But don't forget the
issue of time zones, either. Or the fact that the longer plane
trip is relevant; it certainly makes it more difficult to set up
meetings on short notice, if something unexpected comes up. As
for the language: that can play a role, too, but I expect
cultural differences could play an even bigger role in making
communications difficult. (I've worked on some joint
French/German projects, and even there, cultural differences
created a lot of difficulties.)
We've got a contract coming over the horizon where the client
is in the Middle East. That puts the Bangaloreans closer than
us, and nobbles the lanuguage edge. How about then?

A priori, there's no reason a firm in Bangalore couldn't make an
offer just as legitimate as yours. But in the end, there are a
lot of issues that the client will consider.
 
J

James Kanze

I am still wondering what the definition of this is.
Could you please expand on this, how does using software tools
change software development to an engineering discipline?

What tools are you talking about? I thought the issue was
software engineering; software developed using a established
methodology which is known to work. Engineering, and not pure
research.
Do the programs provably work?

To some degree.
To the same extent that an engineer could "prove" that the
bridge they designed will work?

The that extent, yes. But I suspect you're over-estimating
just how certain it is that a bridge will work. There've been
serious bridge failures as well.
What kinds of metrics are used?  Does software have a stress
point beyond which it will deform, like the metal in the
bridge will?

See http://www.sei.cmu.edu/. I obviously can't stuff a four
year course in software engineering into a web article.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top