BK said:
Not everything I do is rewrite, I have a nice balance bewteen new and
rewrite. I appreciate some of you comments, and I would never say that
ANY tool I've used was perfect, but the more I work with.Net the more I
am impressed with the platform
There's nothing wrong with .Net as a platform. What I said was VB.net falls
short regarding cost effective code re-use (my opinion).
AFA the "new" code you write, how much is truly new? Business logic may be
specific for your company and a new UI may be required, but you're still
just doing accounting, or searching databases, or keeping track of this or
that. Once you've written these "new" apps, how often do you suppose you
should have to re-write them? Once in 5, 10, 20 years? Obviously if the
business model changes the app will need to be updated, but from a business
viewpoint why would you ever require a complete re-write?
In my opinion, .Net offers me the simplest RAD tool available. It's
just my opinion and we certainly have no shortage of opinions here.
VB.net is an adequate RAD tool.
I don't agree. Not having a viable upgrade path doesn't force you to
throw out your tools. You are free to continue using Classic VB. Your
install CD's continue to work don't they? Can't you reinstall your
tools on new machines as needed? Old technology dies, new technology
emerges. To be honest, I wished I had kept a copy of QuickBasic 4.5,
it was a great tool. But I didn't and life goes on.
What you say is completely true, 100%. Kind of misses the point, but true
none the less.
Once again, I disagree. They didn't force anyone to upgrade. You are
and will always be free to continue using Classic VB, that is your
choice. My choice is .Net, which is why I'm in a .Net NG, I get help
with .Net here, I give back to those who need help, etc. I don't spend
my time in Java, PHP, etc NG's
You're right, they didn't force anyone to upgrade - they simply took away
that option. The only option they gave was to change development platforms
and re-write all of your existing working code.
But who is wanting to discuss the viability of VB.Net? From what I
see, the "discussion" is coming from people who don't like the product
and are living in the past. I don't tie myself so heavily to a
technology that I can't shift as necessary. Since I'm not so deeply
tied to the technology, I can unemotionally make rational decisions on
what technology I choose. I don't trust or distrust Microsoft, they
are a corporation not a person. They have goals which are guided by
the same desire all companies have, to make money.
Well, the intent was not to discuss the viability of VB.NET. The discussion
was about the costs involved in "upgrading" to .Net, whether a company
"saved" money or "lost" money. I shifted the discussion a bit
(unintentionally) because the real issue of upgrade cost is assets. If you
or your company don't believe that existing code are assets then you're
quite justified in your calculations. If, on the other hand, you think your
existing code has value then you should be including that as well.
Excluding the emotional responses regarding "upgrading", the bottom line is
that if you were a Classic VB user MS showed that they didn't care at all
about your code assets. As you say, MS is simply trying to make money, but
keep in mind that it's at the expense of their developers.
I'd say that any system that stays in production for over 10 years is
doing pretty well. My last .Net project was to replace a FoxPro
application that was in production for 14 years (a DOS application).
My current project is replacing some Oracle front ends (the database is
still the same) that are 8-12 years old. I'd say that's a pretty good
ROI to get that much use out of technology. Moreover, by employing
n-tier designs, I'm betting we'll get even more use out of these
replacements.
BK - A professional developer for 20 years strong
BK, because you've been at this for so long you should understand, more than
most, the point I'm trying to make. In your statement above you continue to
use the word "replace". This implies that you are simply re-writing code
that has worked, and would continue to work, if not for the obsolecense of a
computer platform and/or language. My point is simple: the work that most
developers do is to "put a new face" on something that was already
functional. Developers re-invent the wheel every couple of years, simply
due to a change in technology. All you do is make shoe laces. All most
developers will do is make shoe laces. I'd love to see a software company
realize this and put forth a tool that didn't treat a developer's work as if
it were disposable. But, as you've stated, this is the reality we live in
and we have to move on. I'd simply ask that you carefully consider the
reasons for justifying complete re-writes. The justification is typically
"because we have to", not because "we need to" or "we want to" -- it's
driven by the computer/software vendors.
