Re: How to convince company I should switch to
Re: How to convince company I should switch to
- Subject: Re: How to convince company I should switch to
- From: Larry Gerndt <email@hidden>
- Date: Sat, 17 Jan 2004 16:10:29 -0800
Thanks for the reply, Michael. It's good to hear from other people who are
going through the same thing. I'm trying to decide between the new
PowerPlant X or Cocoa. I still haven't decided. The new PowerPlant X is
completely different from the old PowerPlant, so it would require a lot of
time, but it looks very well designed (as was the old one), and I am in love
with the Metrowerks IDE. On the other hand, XCode's IDE is foreign and
doesn't seem very good at least to me, yet Cocoa itself (the framework) is
bound to be richer than PowerPlant. Decisions decisions....
--__--__--
Message: 11
Cc: <email@hidden>
From: Michael Rothwell <email@hidden>
Subject: Re: *****SPAM*****How to convince company I should switch to
Cocoa
Date: Sat, 17 Jan 2004 18:25:24 -0500
To: "Larry Gerndt" <email@hidden>
I'm facing this situation at work. The application framework our main
business app is using is end-of-lifed, and the replacement options
(even from the same company) are pretty much totally different. I'm
facing a re-write. It will be huge work, and if I do it well, the
visible gains won't be all that significant to the users. On the one
hand, I look forward to it, because the new environment will be
"better" than the old one. On the other, I hate to waste all that
effort just to get back where we are now.
Be careful and thorough when re-writing an entire app. All the little
bug-fixes, workarounds, tweaks and the like that have been made to the
application over its lifetime will be lost when you re-write, and
you'll have to go through the tweak-test-and-fix cycle all over again
for the new application just to get things back to where you are now.
In short, document the behavior of the application carefully if you
re-write it. You don't want to promise "better" and end up with an
application that has less functionality, or different behavior, or more
bugs. People don't generally like surprises -- especially the people
who sign your paychecks.
If the tools you use to maintain the application are simply not
available anymore, then you have to change something, so try to make
the best choice and present it in terms of necessity and cost/benefit.
"Toolkit X simply doesn't exist anymore. To ensure that we can continue
to ship software that works on Apple's new OSes, we have to switch
toolkits. I've done some analysis of the options, and here's the pros
and cons of each, and my recommendation."
I would say that you should go with the standard Apple tools and
libraries to help ensure forward compatibility of your application with
Apple's operating systems, just as I would have chosen MFC over OWL on
Windows. Cocoa is certainly nice, and you can call carbon (and other
c-based APIs) from it at will. Of course, the future on Windows is
DotNet, so neither MFC or OWL would have carried me forever. But MFC
would have carried me farther, and I can re-package some MFC code as
Managed C++ and/or COM+ objects that I can use from DotNet. In a
similar vein, Apple will help you maintain compatibility if you use
their preferred/flagship APIs and tools -- Carbon and Cocoa.
I hope that made some sense. I just woke up.
--
Larry Gerndt
AIM Handle: SonOfTheSonOfMan
Let the truth be told though the heavens fall -- James Garrison
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.