Re: Microsoft Documentation
Back when Adobe swallowed up Frame Technology, I recall
an acquaintance of mine who worked for Frame (and didn't any longer after the change of ownership) saying that most of
the brains behind Frame had departed, taking the real knowledge
about how the program worked "under the hood" with them.
Since then Adobe has put lots of effort into tacking things onto
the edges of FrameMaker, but making changes to its basic operations - for example, adding those multiple levels of Undo - seem to escape them. I wonder if that's an indication that they're still uneasy messing with the core of the program.
Gene Kim-Eng
Adobe did the same with PageMaker when they acquired Aldus. In all the releases since then, they've added features, but to my knowledge they've only dug deep into the code to fix a longstanding bug on one occasion (to be fair, there may be others I don't know about).
But think about it. From the company's perspective, the ROI for adding new features is enormous compared with that from perfecting a product core that's already pretty good. New features are sexier, easier to market, easier to attract new customers with, easier to sell upgrades with. People grumble more when they have to pay for a fix than when they upgrade to get new features.
So software companies are much more willing to apply resources to developing new code than to fixing old code.
As for the brain drain phenomenon when one company buys another, that's short-term effect. The fact is that programmers move on after ten or fifteen years through promotion or burnout whether companies lay them off or not.
Old code is a pain to fix for several reasons aside from personnel changes. Internal code documentation (comments) always got great lip service and was always part of any company's coding standards. Its execution has always left something to be desired, though. ("I'll go back and put the comments in later. Right now I have to find the bug so they can ship the release.") The match between code and design documentation (when there _was_ design documentation) is fairly weak, because, as we all know, once the design doc is done, the code takes on an evolving life of its own and the doc doesn't stay in sync. Programming theories, styles, and languages have changed so much that today's CS grad would have to be an archeologist to get inside the head of yesterday's developer. Etc. Remember, we're not talking about Y2K fixes in COBOL programs; we're talking about getting down and dirty with stuff that was written by some pretty brilliant hackers on a tear.
The same argument applies to Word, PowerPoint, and Excel, all of which were written at the same company that owns them, even if they did steal core ideas from other companies' products.
----- Original Message ----- From: "Shankar" <ss_rajanala -at- yahoo -dot- com>
On an unrelated note, I wonder why Frame
stubbornly refueses to (or maybe just does not
bother to) simplify their interface and make it
more user- or writer-friendly. Is it that the
very features - such as multiple undo's - that
make word so appealing in turn prove to be its
undoing when the doc length approaches 100 pages?
Multiple undos represent more than an added feature. When PageMaker and FrameMaker were new, having an Undo function was a great advance in personal computing--a metaphoric extension of the backspace key. Users were ecstatic. But the logic of multiple undos is different from that of a single undo, and you're talking about major restructuring of the basic program code (see above).
There is another issue, though. When you have a user base that has become comfortable with the style of your interface, it's not necessarily a great idea to "improve usability" by radically changing the interface. This is a paradox that affects any GUI-based software that predates Windows--Adobe products (PM, FM, Photoshop, Illustrator) and Interleaf prime among them.
The makers of these products have made their choices as to how many standard Windows conventions to adopt and how many legacy conventions to retain. We can second-guess them all day long, but I think it would be more productive just to accept what's there and get back to work.
Dick
References:
RE: Microsoft Documentation: From: Shankar
Re: Microsoft Documentation: From: Gene Kim-Eng
Previous by Author:
Re: FW: Graphics in lines of text
Next by Author:
Re: Multiple undo (was Re: Microsoft Documentation)
Previous by Thread:
Re: Microsoft Documentation
Next by Thread:
Multiple undo (was Re: Microsoft Documentation)
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads