Opinions on future development

[m]

We have a rather large application, perhaps a million lines of code doing
everything from database access to gui to painting items on the screen, all
built in VC++/MFC. There are some heavy performance requirements for the
application thus it's development in C++.

I am trying to put my hands around the future development methodologies for
this application. I am looking for any thoughts on what to pursue, is it
taking portions of the application and developing them in managed c++(where
say performance isn't an issue), what .NET technologies are available to
make development easier, etc. There are several reasons for me to consider
alternative technologies, among them are the lack of C++ developers
available in the pool(it's as if C++ is now a legacy technology, it's much
sexier to know Java or some .NET technology) and many of the third party COM
components we use are no longer receiving substantial development(the mftrs
are choosing to concentrate on developing .NET components).

Further, it's likely that the application will be required to morph into
having the ability to live as either a server component(perhaps the
presentation layer is browser based) or a fat client application.

Or do we do nothing and stand pat with VC++/MFC?

Anyone gone through such a transition and what worked and what didn't? Any
recomendations on reading/training material?

Thanks!

 

[Mihai N.]

I think your pro/cons bullets go this way:

Stay with C++/MFC:
- a million lines of code
- heavy performance requirements

Go to .NET:
- lack of C++ developers
- third party COM components

Don't think it matters:
- live as either a server component
- live as a fat client application


I think that if the components do what you need them to do,
you don't envision major UI changes, and they work on Vista,
you can forget about them for now.

Performance might be an issue, but not a major one, in 6 months
the hardware improvements can cover the difference
(let's say it takes you 6 months to migrate, at that time
the new harware will run your managed code as fast as the
curent native one)

So the two main issues are developers and size.
Now, my experience is that good developers are difficult to find,
not matter the language. I don't think .NET languages have more
programmers right now than C++, but it might get there.
Maybe you see more of them because of a fresh batch of VB programmers
moving toward that, I don't know.
But you should remember that you need people with experience,
so you should discard the ".NET newbs"
And they should understand C++/MFC well enough to do the migration!

Second, I don't think migrating MFC to .NET is to easy, so I
would almost think of the UI part as a rewrite.
If there is a lot of processing with little UI, then it should
be easyer.

Long storry short, I would stay with C++/MFC

But I am a C++ guy, so you should also look at other opinions,
this is just my $0.02
In fact, I would also be interested to read that others have to say.