Free Hand Process
Free Hand ProcessIn XpForProducts, there is some discussion about using ExtremeProgramming for developing "products", as opposed to developing a system for in house use by a single corporate customer. I've never done any XP, but I thought it might be enlightening to describe how one real world product (Macromedia FreeHand) is developed. -- CurtisBartley
Disclaimer
Some caveats apply. I never worked on mainline FreeHand development at Altsys/Macromedia, so although I think I understood how the development process worked, I never experienced it firsthand. It's also been a few years since I worked there, so although I think I remember what I thought I understood when I was there, my memory may be a little hazy. For purposes of expediency, I'm going to proceed like I actually know what I'm talking about. Just keep in mind that I only think I know what I'm talking about.
Some Background
My first job out of college was working for a small company in Dallas, Texas called "Altsys", whom you've probably never heard of. Altsys's major claim to fame was that they developed FreeHand, which was originally licensed and sold by Aldus. FreeHand is an application for doing PostScript friendly illustrations and it is sold primarily to professional graphic designers. It competes head to head with Adobe Illustrator. As a consequence of Adobe's acquisition of Aldus, Altsys got the rights to market FreeHand back and was then immediately acquired by Macromedia, so FreeHand is now Macromedia FreeHand rather than Aldus FreeHand.
Prior to FreeHand 4.0, QA was handled by Aldus in Seattle. For every FreeHand release Aldus would hire contract testers who would test until the product shipped, and then they'd all be let go. Then the whole process would be repeated for the next release with new testers. The lack of release-to-release experience on the test team compounded with the obvious communications difficulties of having the test team in Seattle and the development team in Dallas made the QA process a real burden.
For FreeHand 4.0, Altsys took over the QA effort and hired permanent full-time testers. Testers were usually (if not always) professional graphic designers. These testers were themselves customers of the product, and they were familiar not just with previous versions of FreeHand but other related applications such as Illustrator, PhotoShop, and Pagemaker.
Between FreeHand 4.0 and FreeHand 5.0 Altsys attempted to do some serious process improvement. This effort was instigated by the CEO but the actual process changes were the responsibility of the FreeHand development team. This all happened about the same time SteveMcConnell's CodeComplete came out, and that book was fairly influential on the process improvement effort.
The Process
Overview
At the highest level, the development process basically follows the waterfall model. The first phase consists of nailing down the requirements (usually expressed in terms of features that would be implemented). This is followed by a development phase and then a final testing and bug fixing phase.
Choosing of Features
The way features are chosen for a new release is probably pretty typical for the industry. A new development cycle would be kicked off by choosing a feature list for the next release and prioritizing it. At Macromedia, the FreeHand product management staff in San Francisco was actually responsible for this list. This list of features would be drawn from a variety of sources, such as features that were dropped from previous releases, customer requests, sales and marketing requests, and suggestions from the development team. Another obvious source of feature ideas were other products FreeHand users had exposure to, such as Illustrator, Pagemaker, Quark Xpress, and PhotoShop. Some feature ideas were "well known" and would come up for every release.
Development
The development phase is the most unusual part of the process, and to explain it it's necessary to describe the makeup of the development team. For FreeHand 5.0, the development team consisted of about 10 or 12 engineers and 8 or 9 full time testers. Four or five of the testers were "QA/Designers". As the name suggests, QA/Designers are responsible not just for testing, but also for design (in the user interface sense) of features. The FreeHand 5.0 QA/Designers didn't have any formal user interface design training, but then neither did the engineers that did feature design before them. They did have two important qualifications, though -- they were representative of customers of the product (who were themselves graphic designers) and by dint of their profession they at least had general design experience. It is this QA/Designer role that really distinguishes the FreeHand process from other development processes.
Planning and scheduling is done in terms of features. Features are prioritized and highest priority features are implemented first. A QA/Designer and an engineer are assigned to each feature. The QA/Designer might be working on several features simultaneously, but an engineer would only work on one feature at a time. The development of a single feature follows this progression:
Integration Testing
A final integration testing period is scheduled at the end of the development cycle. This period might last several months, but it is much shorter than the traditional testing period because so many bugs were fixed early in the development process.
EditText of this page
(last edited December 18, 2004)
or FindPage with title or text search