Infernosoft Competitors
Secret Internal Document - Not For Distribution!

What's Right and Wrong with Director

Management

Competitive Analysis

Intellectual Property

Career Opportunities

Technical Support

Products

Introduction

Director is an interactive multimedia animation authoring tool with frame-based score and closely coupled general-purpose programming language ("Lingo"). For four years, the author of this document worked on the Director team as a Quality Assurance Engineer. This document lists positive and negative attributes of the Director product and the Macromedia department responsible for it.

What's Right with Director

  • It supports Windows and Macintosh authoring. About 40% of Director sales are to Macintosh users.
  • It can import and display every popular media type: pict, bmp, gif, jpeg, sounds, QuickTime, Flash ...
  • It offers versatile storage of media: internal and external casts, external files, files linked by URL.
  • It is extensible through a plugin API. Many of its features are implemented as plug-ins; third-party developers have created many plug-ins.
  • It can deliver content to CD-ROM through protected files or to the World Wide Web through protected and compressed files (Shockwave).
  • It has boatloads of useful and fun features.
  • It uses a metaphor familiar to those who have done stop-motion animation.

What's Wrong with Director

  • Paint window has tons of unimplemented features and bugs that never get fixed.
  • Lingo is an idiosyncratic programming language with tons of bugs and strangenesses that never get fixed but users learn to work around. It has little in common with other programming languages.
  • Every version introduces new bugs and requires new workarounds.
  • New users must learn all those quirks, bugs, and workarounds.
  • New users don't want to learn Lingo.
  • It has tons of features implemented in different ways. As slick as the plug-in architecture is, it doesn't completely integrate tools into the existing tool palettes.

What's Right with the Director Team

  • It is composed of Windows and Macintosh developers; they are highly skilled specialists in various web technologies and media types.
  • A good product design and implementation methodology has been in place for several releases.
  • Consistent attention is paid to process, predictability, repeatability.
  • Quality is built in to the development process.
  • The team believes that varied interests in the team leads to a better product. A potential employee with a personality and an interesting background is more likely to get the job than an other wise equally qualified but boring nerd.
  • The design process begins with customer visits; product planning is responsive to perceoved market needs.
  • The team strives for 1:1 ratio of Dev and QA engineers.
  • Development and QA engineers are friends, not enemies. They work together to make sure the product is of good quality.

What's Wrong with the Director Team

  • Director is so large that few people on the team are experts with every feature.
  • The Paint window is used to scare young developers. Its code is old, crufty, and incomplete. Large parts of it are in assembler. No one wants to fix it. The belief that no customer wants it fixed and that for technical reasons it should not be fixed is part of the central dogma of Director product development.
  • From a technical perspective, product cycles are too short. Overruns in one version invariably cause a delay in the start date -- but not the planned ship date -- of the next version.
  • Management does not actively encourage employees to learn about advances in their field.
  • Macromedia is arrogant about its "Cyclone" development process: Though it is a fairly common engineering process, Macromedia "invented" it and used it successfully on every product since FreeHand 5, and believes it has no reason to go looking outside Macromedia to see how others have improved it.
  • The UI framework prevents automated testing. The lack of automated testing burns out QA engineers.
  • There is no complete functional specification.
  • When there's a marginal bug in the UI, it is always resolved in the director of least engineering effort. A technical argument that boils down to "it's too hard to fix" wins out over a UI argument such as "it's inconsistent" or "it confuses new users."
  • Every product cycle wrapup meeting has time for complaints about the process. Complaints are recorded but no concrete plans are made for how to fix the problems.
  • The same kinds of complaints are heard at every wrapup meeting.
  • Test suites get rewritten and reworked too quickly. Old test movies disappear, never to be seen again. There is no database of test movies. (There is a single database of test scripts and test movies, but it serves neither purpose very well.)
  • The advantages of platform-independent programming are ignored (perhaps not understood) by the QA department. Test plans ignore the possibilities of test optimization based on shared code. A large part of Director's playback code was written in a machine-independent layer. Tests could be performed on just one platform with a high degree of confidence that there are no platform-dependent bugs. Instead, time is wasted testing common playback features on every possible combination of operating system and platform. (To be fair, there are features that must be and are tested on every platform. But all testing suffers because common code is not being exploited in the test plan.)
  • The QA department has no programming expert and would not know what to do with him if it had one.
  • There aren't enough QA seciton leads or managers for the number of QA engineers. (The QA manager is too busy to hire any and qualified ones are difficult to find.)
  • There is nor formal system for professional educaiton or advancement of QA engineers.
  • Director is the only tool in its class, so the product team is arrogant nad believes that it does not need to address these issues.

What's Right with Director in its Market

  • Director successfully altered its course from a versatile CD-ROM multimedia authoring tool to a versatile World Wide Web multimedia authoring tool (that can also do CD-ROMs). It kept alive, economically speaking, its customer base by enabling them to make the same transition.
  • It's the only tool in its class. Though it has competitors in certain fields, it has no direct competitor in its own field.
    • Video production tools look similar, but aren't the same thing. You cannot use Director to edit Quicktime video clips into a movie.
    • Hypercard is similar but lacks score-driven animation. It does not have nearly the same level of development support from Apple that Director has from Macromedia. It is not a cross-platform solution for delivering multimedia content to the web.
    • Visual Basic is a tool for building first-class applications, mostly for database access. It is not a cross-platform solution.
  • Director is a Macromedia core product, representing about 40% of Macromedia's income. Its sales have been steady for the past several years.

What's Wrong with Director in its Market

  • Director is seen as a huge lumbering beast that's hard to learn and slow to get started making exciting multimedia content.
  • Diretcor users are looking for other tools to do the same job: C++ and Java animation toolkits are believed by some to be more efficient production tools.
  • Flash sales are growing while Director's sales are just steady.
  • College-level multimedia students do not see the davantages in taking advanced courses in Director Lingo programming.
  • Flash is seen as a lightweight fun tool that's easy to learn and quick to build exciting multimedia content. Its sales are growing by leaps and bounds.
  • The sales team doesn't push Director during customer visits as much as it pushes other Macromedia tools.

What I think will Happen

  1. Director 8 will ship on time. Users were overwhelmed by the number of new features in D6 and D7 (even though most of D7's work was hidden "under the hood") and said they'd be happy with a Director release with fewer features. Nevertheless, journalists will pan D8 as a less-worthwhile upgrade than previous versions. Most of the changes are to the user interface and few reflect actual new functionality.
  2. The engineers will all take long vacations and sabbaticals. Some will quit.
  3. From a combination of factors, D8's sales will not live up to management's expectations.
  4. D9 is planned to be a Big Release with some major changes to the imaging and playback architecture. These long-delayed changes require a long development cycle ... and management, in reponse to D8's weak sales, will accelerate D9's schedule. Throwing more engineers at the problem will not solve it.
  5. D9 is released prematurely and sucks badly. Macromedia stock prices tank.

What I would do if I Owned Director

  • Split the team into 1/3 and 2/3. Many engineers should rotate between these two teams so the 1/3 team doesn't rot and the 2/3 team remembers what it is they're supposed to be improving. Engineers and tech leads rotate, but team managers do not. When D is finally put to rest, that manager will become part of the DII team.
  • 1/3, augmented by some new hires, does maintenance on the current Director: port it to coming operating systems; support the needs of Shockwave.com; add a few new features.
  • 2/3, augmented by new hires, does a complete rewrite of Director. It's divided into some teams...
  • Playback Team: Reexamine the event model and the playback engine: get rid of crap from older incarnations; excise any ugly cruft; remove code used to recreate buggy behavior. Make a really beautiful, powerful animation engine with all the effects pipelines, reentrant score renderers, and so forth you've always wanted. Make a really beautiful API for it.
  • Trash Lingo and replace it with a Java engine.
  • Kidnap people from the Flash and Fireworks teams; hire some MetaCreations Dabbler engineers, and create a brand-new indegrated bitmap/vector painting tool. (Hell, while you're ait it, write it so it can be packaged as a separate piece and be integrated into Director.)
  • User Interface team: redesign the UI from scratch. Steal all the good ideas you want to, even from Director. Through a really clever interface, extend Guy Kawasaki's metaphor from Tourist/Sailor to Tourist/Sailor/Lieutenant/Admiral. Director should be completely usable at the Tourist level, yet have a few unlocked doors to the crew kitchen and lookout posts.From there you can unlock the doors to the engine room.
  • Director II needs no compatibility to older versions. This is a fresh start, incorporating only the best of Director. To keep it lightweight, the D7-8-9 conversion utility is a separate application or Xtra.

What's Right and Wrong with Director
Michael Roeder, December, 1999

 

Google
  Copyright © 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 by Infernosoft. All Rights Reserved.