The days of the solitary hacker are long past. While this reclusive species is still
spotted in the wildernesses of academia and shareware, today's commercial engineers
roam the virtual plains in herds, overcoming the incessant problems of bloated
software projects by sheer force of numbers.
Like all human groups, software teams are tied together by a shared language and
environment. On the Macintosh, this common ground often contains a set of MPW
scripts and tools. While most developers prefer the faster compilers offered by
third-party vendors, the scripting and source control capabilities of MPW make it an
indispensable workhorse in team software projects. It even serves as the cornerstone
of many cross-platform efforts involving both the Mac OS and that other operating
system.
Following a few simple principles will greatly reduce headaches resulting from
maintaining a team's MPW configuration. These guidelines may seem obvious, but I
have yet to see a project that followed all of them.
ENGINEERS ARE USERS, TOO
While we may be accustomed these days to thinking of a user interface as a sequence of
pictures, a build environment in MPW is as much a user interface as any other
software system. Like all such projects, designing it naively invites the wrath of your
users -- in this case, the engineers on your team. And unlike most users, they have
your direct telephone number and know where you park your car!
The primary principle of user interface design is to stop thinking "I want to make the
best X ever," whether X is a text engine, file system, image processor, build
environment, or gorgonzola sandwich. That narrow form of thinking leads to excellent
solutions to technical problems but systems that are difficult to use, because the model
of the problem adopted by an engineer is likely to be different from that applied by an
end user. For instance, to an image processing expert, rotating an image is a problem
of accurate and rapid approximation across a grid, but to a scanner operator, the
problem is one of deciding when to rotate, whether to do it automatically, whether to do
it before or after other operations, and so forth. A technically superb rotation
algorithm may completely fail to meet the requirements of the operator in a print shop
if it wasn't originally designed with that environment in mind.
Balance technical problem solving by thinking through in detail how the system will
be used to accomplish specific tasks. Spell out particular scenarios and make sure
your solutions work in them. Otherwise, they probably won't. So, to keep the needs
of your various users in mind, you need to consider not only a normal build, but
auxiliary tasks such as the following:
Never assume that smart people make fewer errors. A rule of thumb is that the
number of errors made is proportional to the number of possible errors, not to the
skill of the user. Error prevention should be one of your guiding principles in any
system design. For instance, don't require three commands in a particular order to
complete a build; a single build should be a single command. If you have user interface
design staff, get them involved with the development environment; their familiarity
with principles such as error prevention and nonmodality could be very helpful.
Most of all, talk to your users. Ask them what they need and what their problems are.
Sometimes their suggestions will be ones you can use directly; more often they won't
hold up to scrutiny as actual designs, but they always indicate a legitimate area of
concern that you'll need to address. Design your system on paper first, and have your
users review your drafts. This time will pay off later in increased productivity.
Many of the principles of modern software design were originally developed for
traditional command-line systems. See The Elements of Friendly Software Design: The
New Edition by Paul Heckel (Alameda: Sybex, 1991). *
CHECK IN THE SYSTEM
An obvious, but flawed, approach to organizing a system of tools and scripts is to put
them all on a server where everyone can reach them. Each engineer is responsible for
synchronizing his or her local configuration with the latest files on the server, and
anyone can improve the scripts in their copious free time. In addition, everyone can
customize their own system as much as they like.
In practice this simple scheme wastes the time of everyone on the team, because no one
ever has the same configuration as anyone else. A typical frustrating conversation
under this system would be:
I can't build the SuperWidgets library. Does it build for you?
Sure! Maybe you didn't get the new SourceGrinder script?
No, I got that yesterday, after I couldn't build Pat's latest brilliant changes to
WhizzySnork. Let's take a look at your copy of the MungePrefix tool.
Hmmm. It seems to match yours. Gee, I don't know what the problem could be. Let's
both do a complete reinstall and try again.
(Repeat until hysteria ensues.)
The solution to the problem of synchronization is to keep the build system itself under
source control. When people run into problems, they'll make sure that they've checked
out the current scripts and tools as well as the current source files,before they bother
you about it. If they don't, they'll look silly. Since that will probably bring back
unpleasant memories from the playground, they'll try harder next time.
For complex projects, you'll probably want to institute a regular build process with
versioning and source archiving. When you archive the sources for a build, don't
forget to archive a matchingrevision of the development environment! You may need to
reproduce that build in the future, for which you'll need the source code and the exact
build system.
In some larger projects, the development environment may be maintained by a group
separate from the programmers who use the system. In that case, it may not be
practical to archive the environment as part of a project build. The environment group
needs to archive the system with named versions, and the project team needs to always
build with respect to a named version of the environment. The project team also needs
to record in its release notes which version of the development environment was used
for each archived build. This allows the build to be reproduced from the two archives.
HAVE AN INSTALLED COPY HANDY
Bootstrapping an MPW configuration for a new engineer can be painful. There is a
chicken-and-egg problem with any script-based installation of an MPW build system.
The scripts you want to use for installation are checked in, but how does the
first-timer get to them? You can write out careful step-by-step instructions, but few
engineers can resist the temptation to improvise. You'll wind up doing it for them after
all when they fail.
Instead, keep an up-to-date copy of a preconfigured MPW on a convenient server. The
new user simply copies the entire MPW folder from the server to the local disk
(remember those licensing restrictions,though!), edits the configuration file, and is
ready to run.
THE DREADED USERSTARTUP*PERSONAL FILE
It's perfectly clear to the development environment designer that the user needs to
type his or her name where it says
Set MyName "Your Name Here"
but no one ever seems to fill in the blanks correctly without hand-holding.
It may be worth your while to write a mini-application that sets up the personal
configuration file in the MPW folder. An hour or two creating a setup application witha
nice, clear modeless dialog will pay for itself a few newhires down the road. More
simply, you can use MPW's Request, GetFileName, and GetListItem commands in a
setup script -- but a single dialog is friendlier.
This application or script should also be stored on the server where you have the
preconfigured MPW folder. With a little clever scripting, you can easily arrange for
the application to be run automagically if the personal configuration file hasn't yet
been set up.
There are a few kinds of setup that can be done programmatically. For instance, if a
script needs to know the monitor size, don't ask users to type it in themselves; an
MPW tool can look at the graphics device list and figure it out by itself.
ESCHEW CLEVERNESS
One of the best programming tips I ever got was from an introductory LISP text I read
a few centuries ago as an undergraduate. It warned against cleverness in coding. On the
surface this would appear to be stupidadvice. Isn't cleverness a requirement for
programming? The problem is that when our own code strikes us as clever, it usually
involves some trick or back door that's both fragile and hard to understand, not only
for the next poor sap who inherits the code, but maybe for ourselves a month or three
from now. Yet these clever tricks are rewarding. Not only does a trick resolve a sticky
problem in one swell foop, but it reinforces our belief in our own intelligence and
resourcefulness.
LISP, being inherently weird, lends itself to clever solutions. So does object-oriented
programming. (I'll spare you the name of a program that buries its resolution of
conflicting filenames -- dialogs and all -- deep in the bowels of a general-purpose
string class.) Scripting languages such as those of MPW andcsh also encourage
cleverness. Remember the scripts to accelerate launching in last issue's MPW Tips
and Tricks? The form in which they were passed to me used a very clever method of
signaling a cold boot: it aliased the built- in End command to Quit, bypassing the
state-saving code in the Quit script. Needless to say, the potential for side effects was
enormous, but no doubt someone enjoyed thinking of it! I changed the cold boot sequence
to write an empty file called DontSaveState in the MPW folder, and the Quit script to
detect and remove this file. It takes perhaps a tenth of a second longer, but it's
comprehensible and free from harmful side effects.
KEEP IT SIMPLE, STUPID
Another common class of difficulties results from redesigning the basis of MPW. It can
be tempting to make big changes to the system, such as by changing the default value of
a built-in variable like Exit, or permanently blanking variables like CIncludes and
RIncludes to prevent conflicts with local headers.
The problem is that this turns a multifunction system into a single-function system,
making MPW useful solely for the build tasks you've planned. Scripts from other
sources won't work anymore, and the existing techniques and skills of people on the
team may become hard for them to apply in the oddly mutated environment. Getting rid
of RIncludes might make some part of your build sequence easier to manage, but what
happens when an engineer wants to DeRez something by hand?
The solution is to avoid changing the underpinnings of the MPW Shell. If you need to add
variables, add them as new variables -- don't mess with the old ones. Don't install
patches that let you add whizzy graphical menus and floating windows if they interfere
with the ordinary AddMenu and Open commands. When you do need to change something,
change it only in the scope of the script where it's needed.
Among other reasons, you may someday need to have more than one build system
installed. Suppose your company is acquired by the Gizmonics Institute and they have
their own MPW configuration. Would you rather throw away yours and try to figure
out how to shoehorn your source code into their system, or be able to run them both in
the same MPW Shell? Or suppose (and I admit this is pretty unlikely) you start
talking with the weirdos down the hall instead of just snickering about them behind
their backs. Before you know it, you'll be drinking beer together and trying to
integrate your build systems. Don't laugh; it happens.
THE JOY OF THEFT -- SHARE AND ENJOY
There are various sources for useful MPW scripts. Instead of trying to do it all
yourself, you can impress your manager by ripping off scripts from CDs, computer
networks, friends, and so forth. Sometimes even magazines have good stuff.
Apple already distributes quite a few useful scripts, such as those in the folder called
DTS MPW Goodies on this issue's CD. Posting a note on a Usenet newsgroup may get you
just the script you wanted in a matter of hours or days (even though you could have
done it better yourself, of course).
Remember to share a little of your own work to balance the karmic load. This is the
philosophy of UNIX®, and unfortunately it's better developed in that culture than in
ours. Don't forget the others in the virtual herd!
TIM MARONEY has been tempered in the forge of computer networks, acquiring a
rough, cast-iron finish that's often mistaken for obnoxiousness. His favorite animal
name is "Kittens," his favorite food is anything dead, and his favorite new game
involves building globe-spanning conspiracies out of overpriced trading cards. Tim
supplements his seven-figure earnings from writing for magazines by developing
software for Apple. *
Thanks to Shad Ahmad, Dave Evans, Arnaud Gourdol, and Eleanor the Wonder Gerbil
for reviewing this column. *