The Naked Flash Designer and the ActionScript 3.0 Algorithm Dope

The Naked Flash Designer

As a general way of making sense out of projects, they are divided into design and development. The design component usually means graphic design, but it can also include the UI (HCI) and information design—the kinds of things Edward Tufte talks about. In other words, design refers to everything that the user actually sees and interacts with. Those involved in design must expose their work to the user. It is in no way shrouded, and hence naked.

Developers’ work, on the other hand, has better cloaking than a Romulan space ship. If something goes wrong, and the program blows a gasket, the user can see a problem, but if things work, even in the most pedestrian program, the programming is invisible. The entire program can be one hack piled on top of another (as was the case with ActionScript prior to ActionScript 3.0), and no one would ever know. So, we programmers are safe to write any kind of code we want, and as long as it works, everyone is happy.

In many respects, most projects are design ones. The look, feel, navigation and interaction of a program makes or breaks it. A beautifully programmed project isn’t worth a bean if it looks poor, is difficult to navigate or interacts awkwardly with the user. Conversely, if a program looks and acts good, no one cares about what’s under the hood as long as it works.

An Exoskeleton for Programs

Suppose for a moment, that all programs had exoskeletons. The exoskeletons would be made up of the code used in the program. Everyone would be able to see your code and the kind of programmer you really are. Not only would they be able to see the kinds of work that designers do, they could simultaneously see under the hood. Ask yourself this: Would you clean up your code if everyone could see it? I know that I would and do. If you write about programming whether its in a book, an article, or a blog, you think about those things a lot, and your code certainly is visible. All of your examples are open to scrutiny.

Oddly, the worse reason that I can imagine to improve my own coding habits is to impress others. At some level, motivation matters. If I am not clear on why programming practices embedded in design patterns and OOP are important and matter for creating better programs, then I doubt I could sustain an interest in design patterns. For me, the practices are important for what they do—namely create reusable code subject to change and renewal.

Confessions of an Algorithm Dope

I doubt there’s anyone who reads this blog who doesn’t want to be a better programmer. (That includes Chandima and me—we’ve read all the comments in addition to the posts we’ve created looking for clues to better programming.) In working with design patterns we’re confronted with the issue of what it means to be a good programmer and write a good program. The other day in thinking about what good programming means I remembered when I was getting started writing code , all I wanted to do was to create better algorithms—

I was an algorithm dope.

At the time I was fascinated by sort algorithms and spent endless hours trying to understand all of the different sort algorithms. To me, a better algorithm meant better programming. I still believe that, but I’ve also come to realize that’s only part of what it means to be a better programmer. However, being an algorithm dope for many years, it blinded me to the larger picture in programs.

A Good Pilot and a Good Programmer

Some years ago when I lived in San Diego I owned an airplane. Looking for things to do with my airplane, I joined a couple of groups, The Flying Samaritans and Liga: The Flying Doctors. We flew medical supplies, doctors, nurses, interpreters, and other medical folks down to clinics in remote areas of Mexico. All of us had instrument ratings and many were commercial pilots. The talent pool of those groups was wide and deep. Navigation was often a challenge, and the landing strips were dirt or sandy soil. We had to check for people, cows and other surprises on these strips prior to touchdown and land a full planeload of people and supplies. For pilots, these flights were a challenge to skills honed by practice and study—really what flying was all about. That’s why pilots who flew commercial jetliners would often fly with us. We got to do the fun stuff.

At one point I was assigned the job of Safety Officer. I was responsible for making sure that the pilots were current and followed the flying rules we had established plus those of the FAA. Also, if any mishap occurred, my job included finding out what happened and integrate new guidelines to avoid a repeat occurrence. On one flight, one of our planes crashed with severe injuries but thankfully no deaths. (A television movie was actually made of the incident!)

When we had a hearing to determine the events that led up to the crash, we learned that the pilot was attempting to fly under a bridge. At the last moment, he changed his mind. When he pulled up to fly over the bridge, he ran into a metal cable that brought down the aircraft. For his defense, another pilot testified that he was a very good pilot and had landed safely at small remote strips without incident many times. Naturally, we asked what was he thinking by flying so low as to endanger himself and his passengers. He angrily demanded,

Are you saying I’m not a good pilot!

What he meant was, “Are you saying that I can’t fly an airplane?” He wanted to know if we were implying that he lacked the skills to make the airplane do what he wanted. We were saying something very different—namely that he lacked good judgment. It wasn’t that he couldn’t fly an airplane, but rather he put himself, his aircraft and his passengers into dangerous situations.

Recalling the landing of Flight 1549 on the Hudson River by Captain Sullenberger, most people saw the ability to land a powerless aircraft on water without serious injury as a marvel in flying ability. Successfully ditching an aircraft on water is no mean feat, but what was more important than the ability to safely make a water landing was the decision to do so. When the power was lost, “Sully” had several options. He was cleared to return to LaGuardia Airport or go to nearby Teterboro Airport, and initially he announced that he was returning to LaGuardia. Landing at an airport is a far more attractive option and in some situations, the safest. The pilot quickly realized, however, that an airport landing was not viable, and so he decided that the best option was to bring the aircraft down on the Hudson River. To me (and I imagine to most pilots), that kind of judgment was the most important feature that Sullenberger possessed as a good pilot.

On top of that, Sully and his co-pilot had a plan. The plan was in the form of a pre-prepared checklist for ditching that particular make of aircraft on water. One of the steps in the checklist was to press the “ditch button.” The button triggered events that closed the outflow valve along with several other open values. By closing the valves, the plane was able to stay afloat longer. Had they not had a checklist to guide them through the steps, they may well have overlooked pressing the ditch button, and the results may not have been as successful as they actually were.

Good Programmers and Stupid Dog Tricks

When I program, I actually believe that there’s nothing I can’t make ActionScript 3.0 do—within the limitations of the computer, Flex Builder or Flash. When I want to test a concept I’ll whip together something that I think of as a stupid dog trick. It gets the result I want. Sometimes I’ll have to work at it for hours or even days or weeks, but by hook or by crook I can get it done. Once I get the stupid dog trick code finished, I’ll start thinking about doing it right if it’s something beyond a test of concept. However, what a good programmer does is to plan first and then write the code. In David M. Bourg’s book, Physics for Game Developers (O’Reilly, 2002), he discusses making a flight simulator. However, prior to writing the code, he suggests beginning with a flight model that lays out what physics are involved in making an airplane fly. The most basic physics for an aircraft are lift, thrust, gravity and drag; so in the modeling process you want to plan for those forces. This comes way before you start thinking about how you’re going to simulate this in 3-D or how you’ll set up the user interface so that the gamer can make the aircraft perform a split-S. You have a basic outline of what you’re going to do before you start writing your code that makes the application.

With all serious projects in programming, I have forced myself to plan first and then start the coding.

One thing that I discovered is that planning can be fun.

When I used to fly, I’d spend hours planning a flight. I’d check the weather along the route, the navigation aids (e.g., VOR’s, radio stations) and make notes about the topography (e.g., mountains, rivers, visible landmarks). Now in flying, this can be a life or death decision. On one flight my wings iced up, and with no de-icer I began losing altitude over a mountain range. From planning, I knew at what altitude the ice would melt, and it was well above the mountaintops. The ATC was a little panicked and instructed me to maintain an assigned altitude, but because I was unable, I told him I would do so as soon as I could. I wasn’t about to attempt something that the aircraft was incapable of doing and possibly stall. No icing had been reported by ATC or in the weather forecast, but having flown the route often, I knew that it was a possibility. I was quite satisfied with myself for good planning. I know that sounds smug, but like good programming that’s been carefully planned and crafted, when everything comes together, there’s a feeling of doing something right. Maybe it is a bit smug, but so what?

A Program Plan is a Principle Plan

Not long ago I had to refactor a disaster done with ActionScript 2.0. The program looked good when executed, but it was one stupid dog trick piled on another. (A stupid dog trick pile!) I pulled all of the code out of the Actions panel, and began work on getting it right. Because I wanted to maintain the UI and graphic design, I had some constraints, but I knew it could be done. So the first thing I did was to create an abstract class to handle navigation. The navigation bar had been split in two, each with a set of buttons displaying an image of a video that would play by pressing the button. Having an abstract class for navigation, I was able to create two concrete classes, one for each segment of the navigation bar. Not only did the navigation buttons trigger a video, they also triggered two text files—one for a header and one for the body text that accompanied the video. So naturally I wanted a class for the text and so created an abstract class to handle text and then implemented concrete classes for the body text and header text.

The focal principles were, (1) program to an interface, not an implementation; and (2) encapsulate what varies. By setting up abstract classes, I was able to make my references to the interface (typing the instances to the interfaces). Anyway, I finished it up, and while my plan was rudimentary—it was jotted down on the back of a discarded daily calendar page,— it was a plan. The other day I ran into a friend who had seen the page where we had the application, and she wanted one like it for her videos. We sat down, and after showing her what to change, she was able to adopt it for her own application.

I did not use a design pattern. Had I used a design pattern, building it would have been easier, but because I followed the principles used in building design patterns, it worked very well. Most importantly, it was easily re-usable on a different application.

Good Programmer’s Checklist

In flying, we used a checklist to make sure that we didn’t forget anything. Usually, the walk-around with the checklist was uneventful, but every now and then, I’d find a problem. One day I found water in the gas tank, and drained out the water as required. Had I not used the checklist, I may have found an unpleasant surprise while a couple of miles up in the sky. Recently, I learned that hospitals are beginning to use similar checklists to make sure that all of the steps in medical procedures are met. The reason for checklists in hospitals is that they have been sued for medical mishaps. (One poor guy had the wrong leg amputated!)

As an algorithm dope, I never needed a checklist. However, as I began paying attention to OOP principles, I decided it was a good idea to have one. The one I made is a bit silly (Programming Checklist) but as an AIR application I can keep it handy on my desktop and it’s easy to use. More recently, I indexed all of the principles discussed so that I could find needed details about the principles easily.

So unlike Flash designers, we developers work in the dark and our projects have no exoskeleton. As long as our code works and the user doesn’t have to wait too long for the program to load, everything is Jake. What’s more, we can create junk code that works, and instead of elegantly adjusting a class or method to make changes, we can cut and paste more junk code and get things to work. If we don’t know any better that’s one thing. However, if we know about good programming practices and don’t use them, eventually our programming souls wither and die. So I’m going to add one more item to the checklist—

Save your programmer’s soul!

Remember, unlike the naked designer, only we know when we’re doing it right.

The The Naked Flash Designer and the ActionScript 3.0 Algorithm Dope by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. ActionScript 3.0 Memento Design Pattern: Flash Media Server 3 Application
2. Free Flash & Flex Developer’s Magazines