In need of .NET advocacy

[Alex]

Thank you for the reply, Olaf

Very tough questions now, you want proof. ;-)

Not exactly. I have to present a case between people that will want hard data.
I am not saying that I would not be able to be convincing without it but it would be so much easier if I was able to say that company BlahBlahSoft made a similar decision and experienced measurable gains.

It is not easy to overcome corporate inertia.

Thanks,
Alex.

 

[Alex]

Hello Nick, thank you for your reply.

Developers have been arguing about how to measure developer productivity for
years. If you notice from my signature, I am a CFPS. That is a Certified
Function Point Specialist. In other words, I am trained and certified
measure developer productivitiy. Most of my data is private and
proprietary. I can tell you this: when translating from function points to
estimates, we use "normalized" numbers to determine the expected
productivity of a developer against a particular feature set. We are very
happy with the productivity of C#. C++ is considered one of the "average"
languages. These are not guesses. They are measurements. (And no, I
cannot share the numbers).

Even not aggregates?

You can get public numbers from http://www.spr.com

I could not find public data on cpr.com, only reports for sale.

The reasons "why" vary from person to person, mostly because each person
finds a different reason for the productivity gains of .Net. Besides, why
do you care? If its more productive, its more productive.

I care because I have been asked these questions when I tried to informally broach the subject to some decision makers.
I've been told that we would have to (a) purchase new tools and (b) re-train our developers, both of which costs.
We are not exactly swimming in money so unless I can demonstrate good ROI in the short-to-medium term, I am not going to have a sympathetic audience.

4) "Future".


I thought you were pulling this stuff together for managers and executives.
Now I'm beginning to wonder.
Is Cor right?

Cor is free to think and say whatever he (or she) wishes. I am free to ignore him (or her).

Your sig notwithstanding, you still work for Microsoft. When a person asks for help in nudging his company towards a platform that YOUR EMPLOYER develops, markets and advocates, making allegations about this person's motives is not your best course of action.

I thank you for your help so far but I can do without the veiled insults.

"Future of the language" affects the availability of developers. These
issues are CLOSELY tied together.

The issue of developer availablity is a real one and I have commented on it separately.
Some people's comments implied more than that.

I dare you to find a professional SNOBOL programmer, for any price.

This is really getting off topic but http://www.google.com/search?q=snobol+resume found a few.

That aside, I already acknowledged this point in my previous post.

5) Framework.

Are you familiar with Design Patterns?

Since before they were called that.

They are usually solutions to problems that only arise in a specific context.
A bunch of "classic" design patters are unneccessary in, say, LISP or Smalltalk.

I am not familar with the intricacies of the framework. My frirst exposure to .NET was less than a month ago and it is still on a part-time basis.
Some examples where the framework simplifies the developer's job would be appreciated.

6) RAD features.
You are kidding, right?

No, am not.

I never spent much time with MFC (I dislike it) and not yet a lot of time with the framework.

7) Programmer availability.

Now, you are being prejudiced. I know many excellent programmers in the VB
ranks, and some pretty lousy ones in the C++ ranks.

Not much disagreement from me here. I have seen (and had to maintain) C++ code that still makes me shake my head in amazement.
However, you cannot deny that since VB 6 is very easy to pick up, there are a lot of people using it who lack the fundamentals of computer science and software engineering.

Also, _your_ projects will have
average developers on them, if not now, then later during maintenance. This
is a fact of life. Average developers outnumber top developers about 20 to
1 in my experience.

Again, I agree completely and my statement was meant as an endorsement of .NET rather than a critique.
This is exactly what can persuade a manager: An average .NET developer will cost the company less that a top C++ developer would, even taking talent and knowledge differences into account. An average C++ developer on the other hand would probably not.

Best regards,
Alex.

 

[Alex]

Thank you for your reply Sean,

Alex, I'm struggling to understand something. You asked for pro/cons to
persuade others and then flat out admitted that you're biased against what
you're supposedly championing.

The only bias that I have comes from familiarity. I've been writing in C++ for a very long time while I have just a cursory exposure to .NET (something that I am working to rectify).

I am very familiar with the shortcomings of C++ but some of the solutions became a second nature to me so I no longer percieve them as overly problematic when applied to myself and others in my situation.

I readily acknowledge the strengths of the .NET platform (at least those that I am aware of) but on the other hand, I find some features overhyped and some omissions uncomfortable (although with the advent of C++/CLI I could have the best of both worlds).

Your statements appear designed to assert that C++ is better than ..NET/C#.

I have NEVER implied that. Perhaps you've became oversensitive from dealing with the people that do?

Some of my statements were biased and some may have assumed the role of the devil's advocate but this is mostly because the people I will have to persuade will be asking me the same questions. Since I think that I will only have one chance to make my case, I need to have answers to these questions. The problem is, I do not have sufficient knowledge of the .NET platform to address these questions so I presented them here in the hope that more experienced people (such as yourself) will supply the answers that are needed.

So far, I got a lot data that I will have to digest and present in a logical fasion.
I would prefer some real world examples of medium-sized companies that made the plunge but one makes do with what one gets.

Best regards,
Alex.

 

[Sean Hederman]

Thank you for your reply Sean,


I have NEVER implied that. Perhaps you've became oversensitive from
dealing with the people that do?

"My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code."

That's the statement that got up my nose. I've done more than my share of
C++ development, and I get irritated by the undeserved "techier than thou"
attitude that some C++ developers have. A language is a tool and nothing
more or less. The idea that someone is an inferior programmer based on their
choice of language makes as much sense as thinking that someone driving a
faster car must be a better driver.

Some of my statements were biased and some may have assumed the role of the
devil's advocate but this is mostly because the people I will have to
persuade will >be asking me the same questions. Since I think that I will
only have one chance to make my case, I need to have answers to these
questions.

Fairy nuff.

 

[Alex]

"My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code."

That's the statement that got up my nose. I've done more than my share of
C++ development, and I get irritated by the undeserved "techier than thou"
attitude that some C++ developers have. A language is a tool and nothing
more or less. The idea that someone is an inferior programmer based on their
choice of language makes as much sense as thinking that someone driving a
faster car must be a better driver.

A better analogy is that one had better be an excelent driver to take advantage of a fast car while for the average driver, a sedan or a minivan would be a much better choice. A person driving a fast car COULD be a better driver who has a SPECIFIC need for that car's performance, or he could be asking for trouble. If I see my neighbour driving a Formula-1 I'd say he's nuts. Hell, if I see Michael Schumacher driving his kid to school in his F1, I'd say he's equally nuts. However, you won't see him driving a Civic on a racetrack, would you?

I just admitted that C# / .NET is a more PRACTICAL choice in most cases. If that is not an endorsement then I do not know what is.


Now, if you don't mind, I'd like to get back on topic.


Just got an email from Ryan Storgaard, a platform advisor from Microsoft Canada, who was kind enough to point me to some case studies (http://www.microsoft.com/resources/casestudies/product.asp). This will take some time to peruse...


Best wishes,
Alex.

 

[Nick Malik [Microsoft]]

Hello Alex,

I could not find public data on cpr.com, only reports for sale.

I said "public". I didn't say "free."

I care because I have been asked these questions when I tried to
informally broach the subject to some decision makers.
I've been told that we would have to (a) purchase new tools and (b)
re-train our developers, both of which costs.
We are not exactly swimming in money so unless I can demonstrate good ROI
in the short-to-medium term, I am not going to have a sympathetic
audience.

You will not get a demonstration from a newsgroup. You will get one from a
demonstration. Have some of the devs write a simple app in C#. Let them
tell you. Better yet, contact the local sales office of MS and have someone
come over and speak with the execs. Walking in to a meeting with an expert
by your side can really help.

Cor is free to think and say whatever he (or she) wishes. I am free to
ignore him (or her).

Your sig notwithstanding, you still work for Microsoft. When a person
asks for help in nudging his company towards a platform that YOUR EMPLOYER
develops, markets and advocates, making allegations about this person's
motives is not your best course of action.

I thank you for your help so far but I can do without the veiled insults.

No insult intended.

5) Framework.

Since before they were called that.

They are usually solutions to problems that only arise in a specific
context.
A bunch of "classic" design patters are unneccessary in, say, LISP or
Smalltalk.

Your response answered my question, but I don't agree with your implicit
conclusion: that you understood what I meant. I suggest that you read up...
your reply was not indicative of someone who is up to date on OO Design
Patterns.

I am not familar with the intricacies of the framework. My frirst
exposure to .NET was less than a month ago and it is still on a part-time
basis.
Some examples where the framework simplifies the developer's job would be
appreciated.

Not the kind of question that can be reasonably answered in a newsgroup. To
get this level of detail, contact your local MS district office and sign up
for one of the many public talks that are provided, or have a pre-sales
engineer visit your site. They will be much better able to answer detailed
questions like this.

I never spent much time with MFC (I dislike it) and not yet a lot of time
with the framework.

Another responder did a fine job of answering this already. Basically MFC
is a fine library but isn't RAD in any real sense. Each control had to be
learned seperately from the other, and features that you would expect for OO
systems, like development to interfaces, was sorely lacking. That has been
fixed in the framework, allowing a great deal of flexibility in the way that
the framework can be used and extended.

7) Programmer availability.

Not much disagreement from me here. I have seen (and had to maintain) C++
code that still makes me shake my head in amazement.
However, you cannot deny that since VB 6 is very easy to pick up, there
are a lot of people using it who lack the fundamentals of computer science
and
software engineering.
agreed.

Again, I agree completely and my statement was meant as an endorsement of
.NET rather than a critique.
This is exactly what can persuade a manager: An average .NET developer
will cost the company less that a top C++ developer would, even taking
talent and > knowledge differences into account. An average C++ developer
on the other hand would probably not.

Hey... two points of agreement in a row!

Seriously, you would be surprised how helpful the folks at your local
district office can be. Assuming you are in the US:
http://www.microsoft.com/mscorp/info/usaoffices/default.mspx

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Cor Ligthert]

Nick,

Before I wrote that sentence you referred too, had I read the reply from
Alex, who started started his first message with.

"Since I am not an experienced .NET developer by any definition"

I readed constantly sentences as

------------------------------------------------------------------
Not really, as it depends on the user of the object to manually call
Dispose() at the appropriate time.

And

My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code.
--------------------------------------------------------------------

I am something longer in these newsgroups you know and all trolling threads
have this kind of writting in the second message. However I can be wrong of
course.

I assume that my message had as least the advantage that this thread became
not such a one as we have seen the last days (When you look in the language
vb newsgroup than it is terrible).



Cor

 

[Olaf Baeyens]

Now, to the bulk of the answers.

Not exactly. I have to present a case between people that will want hard data.
I am not saying that I would not be able to be convincing without it but it would
be so much easier if I was able to say that company BlahBlahSoft made a similar
decision and experienced measurable gains.

It is not easy to overcome corporate inertia.

I know the problem. ;-)

Basically you have to tell them how much more money they will earn if they
would use .NET. ;-)

 

[Olaf Baeyens]

That's the statement that got up my nose. I've done more than my share of

C++ development, and I get irritated by the undeserved "techier than thou"
attitude that some C++ developers have. A language is a tool and nothing
more or less. The idea that someone is an inferior programmer based on their
choice of language makes as much sense as thinking that someone driving a
faster car must be a better driver.

Sean I don't think that in the case of Alex that this is an issue. I don't
feel that he is criticizing anything, but he talks about his own experience
and that is if you like it or not always biased. I really think that if he
was convinced that C++ is much better than C# and MFC better than .NET then
he would really never started to ask for feed-back.



My feeling is that he really wants to move to .NET, but he lacks experience
so we have to help him.



Alex does a great job with this topic and I hope that he somehow publicizes
his findings (in this newsgroup?) so that other programmers might have a
good basis in order to convince their bosses that it is a good step to start
using .NET.



I do agree that a lot of C++ programmers feel superior towards other
programmers, and in most cases they create their programs from programmer
point of view to show off what they can do, but sadly enough those programs
are not very user friendly and in most cases the user must adapt to the
program instead of the programmer adapt to the user.

But this is a real world situation, we have no other choice to accept that
people like these exist, but there are also many C++ programmers that are
not totally like that.



Alex, keep up the good job.

 

[Olaf Baeyens]

Again, I agree completely and my statement was meant as an endorsement of
..NET rather than a critique.

This is exactly what can persuade a manager: An average .NET developer will cost the company less that a
top C++ developer would, even taking talent and knowledge differences into account. An average C++
developer on the other hand would probably not.

Not only this, but an average developer does not have a company in it's
grip.
If you create a program and then the top developer says, pay more or I go,
then you are stuck with him/her because others do not understand tehe
created code.

But I have another interesting new item that would promote .NET programs, is
the deployment and updating.
..NET programs can be put on a server and in combination with a xml file
describing the most recent version, people automatically gets the latest
version of the application without need to re-install.
From IT point of view, this is very nice since I do not have to go to every
machine to check the version and update the program. I just put it on the
server, change the xml file and it is automatically updated.

To be honest I never used it, so I only know it by reading stuff, but it
looks promising.

 

[Cor Ligthert]

Olaf,

This behaviour is called click once update and will be as a kind as standard
version in Net 2.0.

However it is not difficult to make when you use features from Net.

In a program you have than
A simple webservice to see what are the latest version
Check that to your current version
A simple webclient.downloadfile(s) to get the builds
Some renaming functions and it is done.
The only problem is when you have to get a new update program, however even
that is not difficult to implement.

There is as well something already for Net 1.1 in that you see as well a
description for 2.0

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/updaterv2.asp

I hope this gives an idea.

Cor

 

[Olaf Baeyens]

And another interseting thing is form inheritance.
You can create your's custom controls by inheriting a
System.Windows.Forms.UserControl.
Now you get a panel and you drag and drop all the components on it. Create
your functionality, test it and save it.

Open your main program, and now you can drag and drop the full working
custom made control on your main form and see it in action. And you see live
data. The MFC way is very very very cumberson and during the development of
a dialog box, you get these big black spaces that represents your custom
control but you have no idea what it is until you run it.

 

[Olaf Baeyens]

This behaviour is called click once update and will be as a kind as
standard

version in Net 2.0.

That is it!
I forgot the name.

By the time Alex convinces his boss, the VS 2005 will be available and so
..NET 2.0 ;-)
I saw a report that in the VC 2005 (C++? C#?) you can be able to test your
function in design mode? No need to recompile? This could also improve the
development cycle dramatically.

Right now I am porting code that I already created in a .NET program to C++
using MFC, but I get really depressed if I see how complicated the MFC way
is.
One function must be spread to mutiple functions distributed at different
locations. And I am only talking about a simple edit field with a spin
button. :-(

Another control I have to emulate is a control that have one slider, a left
and right static field and a field below that represents the current slider
position.
I have a.NET custom made control that does all that, just drag and drop and
your gone, but now I have to do that the MFC way and and that is a
nightmare.

And I am not talking about tabbed forms and greying out controls. The .NET
way is to create a panel/group box, drop the controls on that and disable
the panel and all controls are grayed out.
The MFC way is to gray every control out manually. This means I have to
create a variable even for the static texts to grey them out.

But this work has to be done, so let's gather some motivation and do the
thing. ;-)

Maybe another point for Alex:
If you do it the MFC way then it takes more time to see something visually.
But if you do it the .NET way then it is very rewarding for the programmer
and the boss because you see your program getting better and better in real
time. Programmers and bosses gets motivated and really love their job,
so become even more productive. Just an idea?

 

[Alex]

I know the problem. ;-)

Basically you have to tell them how much more money they will earn if they
would use .NET. ;-)

Exactly!

You have hit the nail on the head.

The bottom line should be - "This will save us money. HEAPS of money."
However I have to break it down and present some proof.

So far I have:
* Increased productivity --> less time spent developing products (time is money)
* Better integration with testing tools --> less time spent in QA
* More robust code --> less time spent in support
* Easier and "safer" development --> can hire less expensive developers

Did I miss anything?

On the "cons" side:
* Existing developers need retraining (time, money, "beginners' mistakes")
* Supporting yet another technology (old products WILL NOT be rewritten but still supported)

Currently I'm working on the "proof" side.
While I have no reason to doubt your accounts, managers like nicely presented case studies by big companies.

 

[Alex]

Dear Cor,

This is my first reply to you.
I hope it addresses your concerns because it will also be the last one on this subject.

Before I wrote that sentence you referred too, had I read the reply from
Alex, who started started his first message with.

"Since I am not an experienced .NET developer by any definition"

True, I am not. Yet...
I have experience with C++ and Java, as well as other, less popular languages.
I an currently writing a "demo / prototype" project in C# and reading a lot on the subject.
I also regestered to DevTeach 2005 and hope to get something out of it.

Do not confuse lack of experience with ignorance.

I readed constantly sentences as

Not really, as it depends on the user of the object to manually call
Dispose() at the appropriate time.

This comes from my Java experience.
I worte class libraries that used non-memory resources that just *had* to be released in a timely manner.
GC does not solve this problem. Finalizers do no solve this problem.
Requiring the users of the class to call a cleanup function worked but caused a lot of problems due to the fact that they just "forgot" to do it.
In C++, stack based objects and destructors make this specific issue much easier to handle.

My understanding is that (managed extensions to C++ and C++/CLI notwithstanding) managed .NET code uses the same principles.
Was I wrong?

The reason that I mentioned it in the first place is that I think that GC is not the main reson to switch to .NET and in our case, since some of our developers have been bitten by blindly relying on the Java GC, it is not even a "good" reason.

Therefore, I asked for other compelling reasons.

Context is everything.

And

My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will do better with managed code.

Statement based on a experience with C++ plus external resources (boost, loki, ACE, etc.) and Java, plus reading material on .NET and cursory familiarity parts of the .NET framework.

Statement clearly identified as "perception" (not fact!) and the extistance of bias openly admitted.

Perceptions can and do change.

I am something longer in these newsgroups you know and all trolling threads
have this kind of writting in the second message. However I can be wrong of
course.

So you are a regular of this group, yet you spend your time trying to prove that I am trolling instead of adding to the discussion.

Thankfully, others (like Nick, Olaf and Sean) have provided me with valuable information and demonstrated patience and goodwill even when they disagreed with some of my statements.

Alex.

 

[Jon Skeet [C# MVP]]

The reason that I mentioned it in the first place is that I think
that GC is not the main reson to switch to .NET and in our case,
since some of our developers have been bitten by blindly relying on
the Java GC, it is not even a "good" reason.

It's a very good reason - so long as you know what you're doing. Like
almost any other technology, you need to know what it's capable of and
what it's not capable of. It's wonderful when it comes to memory, but
awful for unmanaged resources - so don't use it for unmanaged
resources.

The "using" statement makes disposing of unmanaged resources in C# very
easy for the most part (when you don't need to embed them in objects
themselves) and the disposable pattern makes it easy to extend to the
rarer cases.

You've cited cases where Java developers have assumed that the GC can
cope with non-memory resources in a timely fashion - my counter-example
is that there are plenty of C++ programs which leak memory and wouldn't
if they used GCs. (Yes, there are GCs available for C++, but again you
end up with a particular "dialect" of C++ rather than "plain" C++.) The
GC should only be used to deal with memory, but I find that memory is
the resource I use most often.

 

[Alex]

Hello Nick,

I said "public". I didn't say "free."

Sorry, my mistake. Unfortunately company will not pay at this point (getting them to pay for the DevTeach conference was hard enough) and I will not spend my own money on it. Oh, well, I'll try to find public and free resources.

You will not get a demonstration from a newsgroup.

No, but I may get a link to a case study, if available.

Have some of the devs write a simple app in C#.

I am writing one as we speak.
Managed to convince the powers that be that a prototype shoud be throwaway so it does not really matter if I use a different technology.
Let me tell you, trying to beat the deadlines while learning a new technology at the same time can be challenging...

Your response answered my question, but I don't agree with your implicit
conclusion: that you understood what I meant. I suggest that you read up...

Why don't you tell me what design patterns the framework implements?

As I said, I have a platform to learn and project to complete and it has to be done faster than planned and have more functionality as a proof that the .NET platform makes one more productive... while at the same time gather information for a case to switch technologies.
I don't have a lot of time left to delve into the parts of the framework that do not relate directly to what I am currently working on.

have a pre-sales engineer visit your site.

You see, that's the kind of information that I wouldn't know. Thanks!

Another responder did a fine job of answering this already. Basically MFC
is a fine library but isn't RAD in any real sense. Each control had to be
learned seperately from the other, and features that you would expect for OO
systems, like development to interfaces, was sorely lacking. That has been
fixed in the framework, allowing a great deal of flexibility in the way that
the framework can be used and extended.

Too much flexibility, I'd say. And the (incomplete) documentation is spread all over the place...
Sometimes it is an excercise in frustration to make things work like intended. Grrrr....
Sorry, had to vent, feeling better now

Hey... two points of agreement in a row!

I was not in disagreement with you in the first place.

What I was saying is that there are certain arguments pro or anti the switch to .NET that may hold a lot of weight in our company and there are others that will be dissmissed right away.

Seriously, you would be surprised how helpful the folks at your local
district office can be. Assuming you are in the US:
http://www.microsoft.com/mscorp/info/usaoffices/default.mspx

Slightly off - Canada, Ontario, Toronto area.

Best wishes,
Alex.

 

[Alex]

Sean I don't think that in the case of Alex that this is an issue. I don't
feel that he is criticizing anything, but he talks about his own experience
and that is if you like it or not always biased. I really think that if he
was convinced that C++ is much better than C# and MFC better than .NET then
he would really never started to ask for feed-back.

For the record: MFC is an abomination.

Alex does a great job with this topic and I hope that he somehow publicizes
his findings (in this newsgroup?) so that other programmers might have a
good basis in order to convince their bosses that it is a good step to start
using .NET.

I will.

I do agree that a lot of C++ programmers feel superior towards other
programmers, and in most cases they create their programs from programmer
point of view to show off what they can do, but sadly enough those programs
are not very user friendly and in most cases the user must adapt to the
program instead of the programmer adapt to the user.

But this is a real world situation, we have no other choice to accept that
people like these exist, but there are also many C++ programmers that are
not totally like that.

In my experience, one becomes a better programmer when he/she understands the nature of the tools at his/her disposal, their strengths and weaknesses and how to leverage the former and work around the latter.

C++ programmers have no choice. They have to understand the internals in order to avoid the numerous traps and "gotcha"s inherent in the language otherwise the project they work on will fail.

This is similar to MFC vs. straight Win32. Sure, MFC provided a quick way to so some things seemingly without the need to know what went on behind the scenes but I've worked with people who purported to be MFC experts but had limited understanding of the Win32 layer and the way the MFC wrappers interacted with it. They got stuck whenever they tried to coerce some flexibility out of the framework.

My experience of assembly helped me with C. My experience with C++ helped me with Java.
And, it already helps me with learning C#. By way of analogies:
Why does a==b usually (but not always) different from a.Equals(b)? Because with reference types a and b are actually pointers to the GC heap.
What's a delegate? An object encapsulating a function or method pointer.
Events? Piece of cake - fancy callbacks.

Does the fact that C++ is currently one's language of choice makes that person a better programmer? Not necessarily.
But if one has worked with several different languages and was curious enough to learn what makes them tick, then that does.

Best wishes,
Alex.

 

[Cor Ligthert]

Alex,

I can be wrong I told.

I don't know if I wrong in this, however I miss a great advantage what is
the framework.

This set what is a OS extention, can save you in future a lot of useless
rolout time at your customers. You don't have to add by instance all kind of
runtimers because all is already build in that framework.

As well can using the framework give you a very standarized UI. What
probably will save the client education time, for what he will be glad with.

Maybe for your economic report.

When I was wrong, sorry I did not say it that hard, however I got with your
second message that feeling.

Cor

 

[Alex]

Hello Jon,

The "using" statement makes disposing of unmanaged resources in C# very
easy for the most part (when you don't need to embed them in objects
themselves) and the disposable pattern makes it easy to extend to the
rarer cases.

Can you please suggest what is the preferred way of utilizing "using" when one has several heterogeneous items to dispose?

Thank you.

Best regards,
Alex.