Re: In need of .NET advocacy
- From: "Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 31 Mar 2005 07:21:49 -0800
Hi Alex,
>>Thank you very much for your replies, they (especially Sean's Olaf's and
>>Nick's) were very informative!<<
Glad to be of help
>>1) Productivity increase.<<
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). You can get public numbers from
http://www.spr.com
>>Did the savings come from an easier transformation of the design to code?
>>Faster coding? Less bugs to fix? More efficient tracking of the said
>>bugs? More understandable code? Something else? Did all activities
>>(analysis/design, coding, QA, refactoring, support) benefit equally?<<
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. It's a little
like asking "Why does Broccoli taste better than Asparagus?" You'll get an
argument and no answers. Note that 2.0 (Whidbey) adds a LOT of useful
features, including a unit testing framework very similar to NUnit.
2) Security.
There have only been a handful of security issues reported against .NET, and
all have been fixed in current service packs. Not so for COM over the
years. . (Public info was provided by another poster).
3) Portability and interoperability.
I never raised this as an advantage of .Net. I simply stated the error of
using this as a cost factor over .Net because it is not cheaper to use a
different compiler (with paid support or no support).
4) "Future".
>>Not really an issue in this particular case because future platforms will
>>still support COM and native execution.<<
I thought you were pulling this stuff together for managers and executives.
Now I'm beginning to wonder. Is Cor right?
"Future of the language" affects the availability of developers. These
issues are CLOSELY tied together.
If your company is doing custom software development, even just for internal
apps, this matters a LOT. Ask all those organizations stuck with miles of
Powerbuilder code and no developers around to maintain it, and no way to add
the new features that the business wants, or change the business rules to
keep up with changes in law, policy, or business practices. This is an
EXPENSIVE place to be.
I know of a government agency with a mission critical app written in
SmallTalk, and no way to extend it. It's a nice app, but they needed
integration features, and SmallTalk doesn't give you anything "out of the
box" like .Net (and even VB6) does. Their last remaining SmallTalk
developer doesn't understand integration.
This story is repeated in thousands of companies and agencies, with systems
written in dozens of languages. With the aging of the COBOL population,
this fate will soon befall the estimated billions of lines of COBOL code. I
used to support an app in Simula. Talk about "hard to fix!" Simula is a
wonderful language that no one remembers. I even added one to the pile:
many years ago, I wrote a very useful app for Linguistics research... in
SNOBOL. I dare you to find a professional SNOBOL programmer, for any price.
Availability of developers matters. Over time, it will matter to C++. The
trend has already started, and historically, this trend is a freight train
that cannot be stopped.
5) Framework.
>>Can anyone comment what parts of the framework proved to be "lifesavers"
>>compare to the "old way"?<<
All of it. The structure of the framework is totally different than a set
of wrapper classes around a set of wrapper classes around an API. (COM on
MFC on Win32). You can do things in 20 lines of code in C# that would
require hundreds in C++, and that story is repeated many times.
Are you familiar with Design Patterns? If not, read this to get you
started: http://blogs.msdn.com/nickmalik/archive/2004/12/21/328727.aspx
6) RAD features.
>>MFC had them, no?<<
You are kidding, right?
7) Programmer availability.
>>I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then
>>the market of .NET developers will get a big boost.<<
Now, you are being prejudiced. I know many excellent programmers in the VB
ranks, and some pretty lousy ones in the C++ ranks.
>>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.<<
Your statement is naieve. *All* developers will achieve better results
using C# over unmanaged code because you can focus on the business problem
and not the details of the technology. 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.
No one creates an IDE for top developers, or a language, or a framework.
These tools are there for average developers to increase their productivity
because a 1% increase in productivity applied to 95% of the workforce is far
better for overall cost savings than a 25% increase applied to 5% of the
workforce. Company executives get this, and if you want to be able to speak
with them with a coherent message, you need to learn it too.
>>Reflection, 3rd party tools (NUnit, etc.), ...<<
I commented on third party tools and open source platforms in my previous
post.
I've seen many postings from Java users who were impressed with the
Reflection capabilities of .Net. Personally, I think that reflection is
probably a tad bit over-discussed because it is a 'cool' feature, but for
those applications where it is the right answer (quite a few, actually), it
is absolutely mission-critical, and this capability simply wasn't available
in C++.
--
--- 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.
.
- Follow-Ups:
- Re: In need of .NET advocacy
- From: Alex
- Re: In need of .NET advocacy
- References:
- Re: In need of .NET advocacy
- From: Alex
- Re: In need of .NET advocacy
- Prev by Date: Re: VS Projects keep running after I stop debugging
- Next by Date: SetParent Windows API function notworking with VB 6 forms
- Previous by thread: Re: In need of .NET advocacy
- Next by thread: Re: In need of .NET advocacy
- Index(es):
Relevant Pages
|
