Rewrite ...

  • Thread starter Thread starter Stan Canepa
  • Start date Start date
S

Stan Canepa

This post is mostly for discussion. Why rewrite in .NET? Just a general
discussion not related to any specific details. I was just looking to see
what reasons developers are looking to, to help decide whether they should
rewrite their app in .NET.

What are the trends being observed of Microsoft when it comes to .Net?

How much longer will COM objects live on?

How stable is the Framework?

If the goal is to maintain a software package for the next 10 years, would
that make a differnce on the decision?

What if a rewrite would take approximately 2 years, would that affect when
you decided to do a rewrite?

Are their any security benefits?

I am looking for opinions, but also links to facts that can help support
your case. I'm hoping this can become a good discussion.

Thanks
 
Stan,

Crossposting to so many newsgroups looks for most regulars in newsgroups,
nothing more than the start of a Troll Thread.

Sorry if I misinterpret

Cor
 
No just thought a good cross section would lead to some insightful
discussion. All the groups areDotNet, and cover differnet topics covering
what I am looking for. (Security, Performance, ...) I am really just trying
to gain a perspective on the pros of rewriting a VB 6 app in Dot Net.
 
I would probably begin a rewrite in a very controlled way, hopefully the app
is well modularized where you could take bits at a time? i.e. treat it as 40
seperate applications with a shared base?

Cheers,

Greg Young
MVP - C#
 
Stan,

If it is a let say for the developper dead application, which needs never
maintenance than let say changing some values which could have been external
but just need to be changed one time a year, than there is probably few need
for changing if you are sure that it is that dead that even the hardware and
OS will not change the comming ten years. In my idea is the last an utopia
thought by people with no expirience in that.

Otherwise it is wise in my opinion at least to investigate what it does
mean. However, a newsgroup can never know all your ins and outs and can in
my opinion therefore give you no answers on that.

Big banks (and companies like that) are seldom changing there software which
is not direct seen by the client, just because not changing it is moslty the
safest. They came in trouble before the year 2000 when they had to make
changes. It was hard to get the hands to do that in that time.

Just my idea

Cor
 
Hi Stan,

Based on experience from what my organizations does:

Most of our customers are looking for a platform shift from VB6,
C++/ATL, ASP, etc. to .Net 1.1 or .Net 2.0. Some have shifted. Some are
shifting. For some we developed and managed the old technology
code-bases and are doing new portings, and other clients come to us
because they want to move their old code-bases to the newest platfotms.

Reasons you ask?
1. For Product companies, it can be a matter of survival to be
available on the latest platform.
2. Talent Pool - it becomes harder and costlier to find developers on
older technologies, because they become scarce. At least in India, most
people would rather be learning to make applications on .Net or J2EE,
rather than C++ or VB.
3. Code Maintenance and Speed of Development (Time to Market) - RAD
tools, Configuration Management, Code Review, Automated Testing,
Builds, etc. - more of these things are available for newer platforms
than older ones. These help bring a lot of value to the project
development life cycle, and so reduce a lot of cost for development of
the product (be it maintenance of old code, or doing enhancements). I
mean, I can perform much better in VS 2005, as compared to VS 6.
4. Stability - debatable, but generally, newer technology tends to be
faster and more stable.
5. Security - of course, unless you are an expert (which most
developers are not), then you are liable to leave more security holes
in a VB6 app as compared to a .Net app. Newer platforms, leave less
room for shooting yourself in the foot.

There are MANY MORE reasons i am sure, but i thought at least i will
add some to kick off a discussion.

Regards,
Vaibhav
 
I have just started programming in VB.net and learning it as I go.
I have been programming ( to pay my bills ) since '98 and some things I
learned in school are outdated already, and some have
changed so much I am outdated. Some languages I have learned at some places
such as ( 4GL ) I cannot use anywhere else,
and others were so unique its not beneficial to continue in them.

From my perspective, I think it would be beneficial to start
updating/learning .net.

A programmers life span is about 5 years ( apparently ) before they need to
upgrade themselves.
Your programmers would be learning an up to date programming language while
maintaining your old one.
Basically you would be funding the "schooling" for them to update their
skills.

If you choose not to update for 10 years, how long will your programmers
choose to write code in vb6?

At least that way - you will see any hiccups that will arise in the future,
and perhaps even code some things
in VB6 differently to make a transition later on more easily.

If you set aside 3 or 4 hours a week per programmer ( an afternoon ) where
they can start to program in .net, / try
to take a module and bring it up to the new version - This would at least
give you an idea of their complaints or likes
about the new version.

Do it now, while it is still financially feasible to take a couple hours off
each programmers "income time".

Im programming in my current languages, but I have realized... to learn
something new that "might" help me out later on,
is more beneficial then to learn nothing new at all.
Why not ask your programmers what they would want to do? - a happy worker is
a productive worker.

My 2 cents.

Miro
-And if anyone else reads this on the vb.net newsgroups - Thank you for you
help as I walk up the learning curve.
 
Hello Stan,

I'll answer some questions inline.
This post is mostly for discussion. Why rewrite in .NET? Just a general
discussion not related to any specific details. I was just looking to see
what reasons developers are looking to, to help decide whether they should
rewrite their app in .NET.

What are the trends being observed of Microsoft when it comes to .Net?
Click to expand...

Generally Line-Of-Business apps were being rewritten in .Net before larger
system apps. New app development has moved substantially to .Net, although
there are some folks still developing new apps in older technologies. Now
that SOA apps are gaining in popularity, a proliferation of
web-service-based apps/services are emerging, largely in .Net because it is
so much easier to develop and debug them there.
How much longer will COM objects live on?
Click to expand...

I'm not in the product groups, so I cannot say. I don't believe that COM is
going away any time soon. However, with the flexibility of WCF, I'm not
sure that COM is the first choice I'd jump to for new components that I wish
to share and manage.
How stable is the Framework?
Click to expand...

Extraordinarily stable. Probably the most stable chunk of software that
Microsoft has ever produced.
If the goal is to maintain a software package for the next 10 years, would
that make a differnce on the decision?
Click to expand...

Nope. In 10 years, you will change technology twice. When you change
depends on you, not on the technology available at the time.
What if a rewrite would take approximately 2 years, would that affect when
you decided to do a rewrite?
Click to expand...

Nope. See above. In Microsoft IT, we tend to replatform apps once every
four to six years.
Are their any security benefits?
Click to expand...

Yes, but it depends on what you are doing. Normally, when folks rewrite,
they are also adding features and often changing the architecture of the app
to meet newly understood requirements. The new architecture will have a
greater impact on security (in a good or bad way) than the language or
technology.
I am looking for opinions, but also links to facts that can help support
your case. I'm hoping this can become a good discussion.

Thanks
Click to expand...

To the core question: why rewrite in .Net: Because you want to add features
to your app, and you want to update the architecture to meet new needs, and
you want to maintain it for a while, and your developers know, or want to
know, new technologies. All pretty typical reasons. I don't normally
advocate rewriting for the sake of rewriting. On the other hand, if you
have an app that is eight years old, it probably needs updating, because the
requirements were gathered nine years ago, and no matter how good your
analysts were, unless they were good at predicting the future, your app is
missing some things that you need to add.

If your app is two years old, I'd be curious about why it isn't in .net
already. The platform has been out for many years now.

If you don't think the needs are going to change for a while, leave it. The
older technologies aren't broken. They are just technologies. All
technologies change. That shouldn't be a reason, by itself, to change your
app. Change your app when the requirements change. Use fairly new
technologies each time. Simple as that.

--
--- Nick Malik [Microsoft]
Enterprise Architect
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.
--
 
Nick Malik said:
Hello Stan,

I'll answer some questions inline.


To the core question: why rewrite in .Net: Because you want to add features
to your app, and you want to update the architecture to meet new needs, and
you want to maintain it for a while, and your developers know, or want to
know, new technologies. All pretty typical reasons. I don't normally
advocate rewriting for the sake of rewriting. On the other hand, if you
have an app that is eight years old, it probably needs updating, because the
requirements were gathered nine years ago, and no matter how good your
analysts were, unless they were good at predicting the future, your app is
missing some things that you need to add.

If your app is two years old, I'd be curious about why it isn't in .net
already. The platform has been out for many years now.
Click to expand...

Simple - VB 7.x (.net 1.x) was a lousy upgrade for VB 6 programmers. VB
2005 is a much better, but not perfect, upgrade path for VB 6 programmers.
If you don't think the needs are going to change for a while, leave it. The
older technologies aren't broken. They are just technologies. All
technologies change. That shouldn't be a reason, by itself, to change your
app. Change your app when the requirements change. Use fairly new
technologies each time. Simple as that.
Click to expand...

Agreed. Don't rewrite an application just because there is a new
technology. Any rewrite should be for major revisions - minor revisions can
be done in the original technology/language.

Mike Ober.
 
Thanks for the input.

We are considering doing a rewrite of an app that is 7 years old, and you
are right it is just missing functionality. And the new functionality added
into the app, was forced into the structures to make it work. The app also
has several modules all basically its own application, but they all work
together. If we do the rewrite it would be to unify everything, so that they
all can share the same business rules and interface. And to create a better
database design to help make maintenance and support a lot easier.

My biggest concern is that we are a small shop and the rewrite will take
about 2 years. I don't want to wait too long and be behind the eightball,
but I also don't want to move forward with a technology that is still
developing itself.

I know no one can answer these questions for me, but it's still good to get
feedback from people dealing with the same issues.

Thanks
 
I would probably begin a rewrite in a very controlled way, hopefully the app is well modularized .... <<

We all wish!
 
Stan,

I'm a developer and I've been at my company for 6 years. I developed
well over 60 programs in VB6 and when .Net came out I debated whether
we should move. The decision was left up to me. I made the decision
to go with .Net and have spent the last two and a half years rewriting
everything in .Net so we don't have to deal with two languages. My
reasoning for doing it:

1. Support for VB6 in terms of service packs is going away sometime.
2. The new IDE is so much more productive than VB.Old.
3. I came from a C++ background so .Net is more familiar to me and
it's not as daunting to me as those that learned only VB6 or before.
4. COM isn't going away any time soon. The framework works very well
with COM, whether it's calling COM or being called by COM.
5. .Net is faster and more stable than VB6.
6. I had to write some programs for handhelds using eMbedded Visual
Basic. .Net includes the Compact Framework. If you've ever had to
develop using eVB you know why this is a no-brainer.

I don't want to start the religious war of VB6 vs. .Net but I did want
to put forth my reasoning for taking my company down the .Net path.

Dave Campbell, MCAD
 
Stan,

Your problems are what many face all the time. An alternative to a
complete re-write would be a phased portation. Where-in your
application has a period where it exists in both the technologies
side-by-side.

Also, (controversial as the topic may be) you can outsource the work.
My company does this kind of work all the time (not trying to
advertise).

Regards,
Vaibhav
 
Stan,

I've been writing tons of from-scratch apps, large and small, since VS
1.0 was released. It takes a lickin' and keeps on tickin'. It really,
really is stable and you can have confidence in it. I've NEVER had a
bug that wasn't in *my* code, and believe me, I much prefer those
because I can DO something about them.

It's without question the most stable environment I've been involved
with since I started writing software for a living in 1983. And that's
saying a lot, because back in the day I was a FoxBase / FoxPro / Visual
FoxPro guru and I considered THAT the benchmark for a rock-solid
platform until I got involved with .NET. .NET has held together
superbly for console apps, windows services, .NET remoting, winforms,
and ASP.NET projects I've done.

The only caveat is that my experience with the 2.0 CLR is a lot thinner,
consisting so far of just a smallish Winforms app. I've heard nothing
but good about the 2.0 CLR itself, but there is a little bit of
grumbling about VS 2005, and I ran across a couple of annoying but
surmountable problems with it in my project. Basically the IDE was
released just a wee bit before it was fully baked, but arguably some of
the grumbling is just because VS 2003 had us so darned spoiled ;-)

At any rate I wouldn't hesitate to recommend it as a platform. In my
personal view it beats a multivendor platform with fingers pointing
every which direction when something doesn't work correctly.

Best,

--Bob
 
Stan Canepa said:
Thanks for the input.

We are considering doing a rewrite of an app that is 7 years old, and you
are right it is just missing functionality. And the new functionality
added
into the app, was forced into the structures to make it work. The app also
has several modules all basically its own application, but they all work
together. If we do the rewrite it would be to unify everything, so that
they
all can share the same business rules and interface. And to create a
better
database design to help make maintenance and support a lot easier.
Click to expand...

I have an app in my portfolio that looks remarkably similar to what you just
described. We are about to rewrite ours as well. It was written,
originally, in SQL 6.5 and VB3, but has been maintained up to using SQL 2000
and VB6. Now, we are planning a complete rewrite to include new features,
combine interfaces, clear out some old ideas from the database structure,
make the data more useful for other apps to consume, and make it easier to
use.

Sound familiar?
My biggest concern is that we are a small shop and the rewrite will take
about 2 years. I don't want to wait too long and be behind the eightball,
but I also don't want to move forward with a technology that is still
developing itself.
Click to expand...

The technoloty is not "still developing itself." .Net technology is fully
baked. Microsoft has over 500 Million Dollars invested in applications and
solutions written in .Net to run our rather complex multinational software
business. That doesn't include products. That's just to run the company.
In Microsoft IT, we have thousands of developers writing code in .Net. We
have bet the business on this platform, literally. It works Exceptionally
well. The .Net platform is fast, stable, secure, and reliable. Do not wait
out of fear of the platform. You may have very good reasons to resist
change, and I completely respect those reasons. However, the platform's
maturity is not a valid reason to wait.

As for the time and cost:

www.rentacoder.com
www.elance.com

It is amazing how low the price can go when a shop in India is competing
with a shop in Russia, and they both have good track records with smart
programmers on staff. I've gotten fairly nice systems for under $5k.

Even if you outsource, you will still have two years before the new app is
"done." Six months to get the new app in, four months to stabilize the
initial features and pass User-Acceptance-Test, and then a couple of
iterations to add the features that the users want but were never able to
ask for, or get, before :-). But that's just IT.

--
--- 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.
--
 
Back
Top