ACT! 2005 Complaints with MS .Net

[Guest]

Hi,

The following is a representative comment from the ACT! User Forum regarding
their newest version, 2005.

"I didn't say the product was fast enough...

I suspect most of those issues are related to .Net and if so, won't be able
to be fixed till the version after MS releases .Net V2"

There have been many user complaints voiced on the forum regarding the
slowness of the application, particularly when switching screens. The common
defense on the part of many consultants tied to ACT! through their service is
that the problem is with the .Net application.

I suppose most readers just want to know whether that claim is valid. There
are some posters who believe that other .Net applications run well. A number
of posters believe that the performance problems are a direct result of the
way ACT!'s code is written.

Is there anyone on this board who can shed any light on this dilema?

Thanks in advance for any thoughts that can be shared.

Jeff

 

[Jon Skeet [C# MVP]]

The following is a representative comment from the ACT! User Forum regarding
their newest version, 2005.

"I didn't say the product was fast enough...

I suspect most of those issues are related to .Net and if so, won't be able
to be fixed till the version after MS releases .Net V2"

There have been many user complaints voiced on the forum regarding the
slowness of the application, particularly when switching screens. The common
defense on the part of many consultants tied to ACT! through their service is
that the problem is with the .Net application.

I suppose most readers just want to know whether that claim is valid. There
are some posters who believe that other .Net applications run well. A number
of posters believe that the performance problems are a direct result of the
way ACT!'s code is written.

Is there anyone on this board who can shed any light on this dilema?

I haven't used ACT 2005, but .NET itself is pretty nippy for the most
part.

I *hope* ACT 2005 is better designed than previous versions of ACT, but
having written code to use those older versions, performance problems
there were due to poor design IMO - the same *could* be true now. As I
say though, I haven't used the latest version. If the consultants could
be more specific in terms of which part of .NET was the bottleneck, it
would be easier to verify what they're saying.

 

[Guest]

Hi Jon,

Thanks for your response. I upgraded to ACT! 2005 last October, and found it
to be unacceptable for my use. There were a lot of the features that I
utilize that had not been carried forward to the new version, and there were
some real indiosyncrasies that made it unacceptable.

Supposedly the previous versions of ACT! were written utilizing a different
type of database. 2005 was written for .Net. (I know nothing about database
software... so I really don't know if I am referring to it properly.)

The people that are defending ACT!'s version 2005 have stated that it is a
complete code rewrite, and there have been many references to .Net being some
industrial strength app that is more suited to a networked configuration with
multiple users, than it is to standalone configurations of individual users.
Many upgraders have followed the suggestions of board members and purchased
more high-powered hardware only to find out that the speed of the standalone
app was still far slower than the previous version.

If .Net is slowing things down because of the nature of the beast, then I
suppose we will all have to deal with it. If, however, the code rewrite is
the problem, and .Net arguement is nothing but a smokescreen, then criticism
can be directed where it belongs.

Thanks again for your reply.

Jeff

 

[Nick Malik [Microsoft]]

Hello Jeff,

I cannot speak for the ACT! code. I have not used any version of ACT! What
I can say is that I have FREQUENTLY seen complaints that apps ported from
C++ or VB6 to .Net run slowly. I looked into one of these situations in
detail. This was in a consulting engagement, so I cannot discuss what the
application itself was.

What I found was that the developers of the previous application were
programmers who were more familiar with DBaseIV and BASIC than they were
with good programming practices (even some CS grads in there). The best
level of software development that they had reached was the very beginning
level of good structured programming practice (circa 1985). To a man, not
one could explain why a developer should ever use inheritence, or even a
good approach so that the design that could be evaluated seperately from the
code.

In other words, it would be like a good carpenter building a house without
blueprints. There are going to be mistakes, and they will affect the
quality and value of the house, as well as its performance in adverse
circumstances.

In the case that I am speaking of, the answer was to go back and use good
architectural and design practices to refactor the application. The code
was fundamentally transitioned to an Object oriented software base. The
resulting application was FASTER than the C++ app that it replaced, and
allowed for much better use across a network, and much better communication
with other applications.

Adding powerful features to an app is a good thing to do. When the person
doing the "adding" is not trained in the details of the new platform, they
are going to make mistakes. Without a vision of how to get there, even
coding heros can't overcome the mix of new technology and old practices.
Performance suffers.

It is hard to blame .Net for that.

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

 

[Jon Skeet [C# MVP]]

Thanks for your response. I upgraded to ACT! 2005 last October, and found it
to be unacceptable for my use. There were a lot of the features that I
utilize that had not been carried forward to the new version, and there were
some real indiosyncrasies that made it unacceptable.

As opposed to the idiosyncrasies that made previous versions
unacceptable? (I always found the ACT UI pretty awful, I'm afraid.)

Supposedly the previous versions of ACT! were written utilizing a different
type of database. 2005 was written for .Net. (I know nothing about database
software... so I really don't know if I am referring to it properly.)

The people that are defending ACT!'s version 2005 have stated that it is a
complete code rewrite, and there have been many references to .Net being some
industrial strength app that is more suited to a networked configuration with
multiple users, than it is to standalone configurations of individual users.
Many upgraders have followed the suggestions of board members and purchased
more high-powered hardware only to find out that the speed of the standalone
app was still far slower than the previous version.

If .Net is slowing things down because of the nature of the beast, then I
suppose we will all have to deal with it. If, however, the code rewrite is
the problem, and .Net arguement is nothing but a smokescreen, then criticism
can be directed where it belongs.

Well, .NET certainly is industrial-strength, but that doesn't mean it
can't cope with individual users! If they're using a decent database
(such as MSDE, which is ideally suited for this kind of thing) that
should improve things too. The old database was pretty ghastly.

My guess is that .NET may be slowing things down due to being used
poorly - if they're using programmers who have worked on ACT! for a
long time, they may not be really familiar with .NET, and may be using
it very badly. As with pretty much every platform, if you use it badly,
you'll end up with terrible performance.

My experiences with previous versions of ACT don't inspire me with
confidence frankly - I would hope that with a fresh start they could
have a significantly better database organisation and better code
design, but without looking at the database and code, it's hard to
say...