Rewrite ... -- dotnet general

dotnet general : Rewrite ...

Stan Canepa
5/9/2006 10:32:29 PM

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 Canepa
5/9/2006 11:36:34 PM

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.

[quoted text, click to view]

Greg Young
5/10/2006 12:41:27 AM

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#
[quoted text, click to view]

V
5/10/2006 2:24:40 AM

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

Cor Ligthert [MVP]
5/10/2006 6:27:32 AM

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

"Stan Canepa" <scanepa@docksidesoftware.com> schreef in bericht
news:e0dSfJ%23cGHA.380@TK2MSFTNGP04.phx.gbl...
[quoted text, click to view]

Cor Ligthert [MVP]
5/10/2006 7:24:27 AM

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

"Stan Canepa" <scanepa@docksidesoftware.com> schreef in bericht
news:e1u1Gt%23cGHA.1204@TK2MSFTNGP02.phx.gbl...
[quoted text, click to view]

Nick Malik [Microsoft]
5/10/2006 8:31:21 AM

Hello Stan,

I'll answer some questions inline.

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

Extraordinarily stable. Probably the most stable chunk of software that
Microsoft has ever produced.

[quoted text, click to view]

Nope. In 10 years, you will change technology twice. When you change
depends on you, not on the technology available at the time.

[quoted text, click to view]

Nope. See above. In Microsoft IT, we tend to replatform apps once every
four to six years.

[quoted text, click to view]

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.

[quoted text, click to view]

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

Miro
5/10/2006 9:39:22 AM

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.

[quoted text, click to view]

Michael D. Ober
5/10/2006 10:42:16 AM

[quoted text, click to view]

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.

[quoted text, click to view]

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.

Stan Canepa
5/10/2006 4:36:26 PM

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

[quoted text, click to view]

Dave
5/11/2006 4:30:33 AM

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

V
5/11/2006 7:29:49 AM

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

[quoted text, click to view]

Stan Canepa
5/11/2006 8:20:07 AM

Thanks for the input.

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet general

View Other Months
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008

home · blog · groups

Questions? Comments? Contact the dn