Safe from the Losing Fight

Recently I came to the conclusion that I should write about JavaScript menus. Why? Well, the other day I was searching for my name in Google and noticed that the top hits, and most of the hits, were related to mm_menu.js and fw_menu.js. Now I know its bad form to Google for your own name, but trust me, I was provoked. I noticed in my local blog searches people were searching for menu and mm_menu, despite the fact that I have never written about them on this blog. So why were people looking for them here? It turns out the very top of the mm_menu.js file has this:

/**
* mm_menu 20MAR2002 Version 6.0
* Andy Finnell, March 2002
* Copyright © 2000-2002 Macromedia, Inc.

Ah, in those days I was young and foolish. Foolish enough to leave an electronic paper trail back to me. You don’t see me making that mistake again.

I ended up looking at a lot of the sites that referenced mm_menu or fw_menu. They are typically web developer forums. Most the conversations on said forums go like this:

Newbie: I’ve got these mm_menu.js menus, and I want to them to scroll/delay showing/be horizontal/play the harmonica.

Expert (usually Murray): Those menus suck, don’t use them.

Newbie: But I have most of it working already. I don’t want to start over again.

Expert/Murray: Curse you Marcodobia!

The conversation usually goes downhill from there. There’s also the misunderstanding that I own those menus or even created them. One poster suggested that they take up a collection and pay me to add more features. Ha ha! Dude, I like the idea of you giving me money, but not the idea of me coming within ten miles of the menu code.

How did I get involved with this if I’m not the creator of this mess, you ask? *sigh* Well, if you insist on asking me that question, I guess I have answer it.

I was tricked into it, like most things. I had just started on the Fireworks team at Macromedia when they were trying to push out Fireworks 4.0.2, a bugfix release. The JavaScript menu feature had been released in the 4.0 release, and they had a serious bug already. This would have been a warning sign to anyone with experience, but not me. My boss innocently said, “Say Andy, we’ve got this one simple bug in the menus code. Could you take a look at it?” Not realizing that was manager code for “Run! Run like the wind!” I said “Sure” and went to work. It was a bug in Internet Explorer. A bug that started my hate-affair with IE. I managed to get a work around in that didn’t bloat the code too much more than the already 20k it was at. I thought that was the last I’d have to deal with that code. But no. Through the scientific process of “you touched it last, you own it” I now had to maintain it for the rest of my career at Macromedia.

You see, I didn’t even create this mess. It all started with some dude over at Netscape named “Gary.” (Most likely a pseudonym. He probably had enough sense not to leave his real name on anything.) He wrote this JavaScript library that allowed menus to be created on the fly in Netscape 4. Yep. Netscape 4. As the legend goes, towards the end of the Fireworks 4 development cycle, someone decided JavaScript menus would be a great feature for Fireworks, a graphics program, to have. The engineer tasked with this feature didn’t have time to write such a thing himself, so he searched for something to start from. As fate would have it, he found “Gary”‘s JavaScript menus. Noticing that the JavaScript file wasn’t near bloated enough, the engineer added support for Internet Explorer and the then alleged Netscape 6. He managed to get it up to 25 kilobytes. Take that you 14.4kbps modem users.

For reasons now obvious, that engineer quickly fled the company and the state soon after the Fireworks 4 release.

Which left naive little me to deal with them. The next version of Fireworks, MX (Yeah, I know that’s not a version number, but tell it to the marketing guys. They have trouble with numbers vs letters.), was supposed to have many improvements to our hit feature, the JavaScript menus. By “hit feature”, I mean everyone loved them until they figured out how badly they sucked. Fortunately for us, you can’t try out a feature when the CD is still in the box.

Learning how the menus even worked was a huge pain the backside. It was a lot of non-obvious, uncommented code. But I figured it out and added all the features management claimed we needed, and managed to bloat the code by 5k. It was also during this time I realized what a mess it was, and how badly we needed to scrap it and start all over again. I also helped tech support and customers out by telling them how to hack the code to add features we weren’t going to add directly. This was a mistake because, once again, I used my real name.

When we released MX, the customers marveled at how much code I managed to add without really improving anything. The experts complained because the menus were still huge, slow, inaccessible, un-crawlable, and didn’t work if the user had JavaScript turned off. The newbies complained because although all the new features were nice, they just needed one more feature before they were happy.

Al Sparber just laughed his way to the bank. (He sells competing HTML menus.)

For the next release there were murmuring of adding even more features. That’s when I pulled the engineer trump card and told them that new features couldn’t be implemented unless the menus were rewritten. That thoroughly killed menu work for the MX 2004 release. I began internally campaigning to have a new set of HTML/CSS menus created (there were lots of examples of these popping up externally).

There was a lot of internal movement between the MX 2004 and 8 release of Fireworks. I used that time to write a new version of the menus using HTML and CSS with a little bit of JavaScript. I cleverly substituted bloated JavaScript for bloated CSS. heh heh. That’ll show those experts. This was about the time I got moved off to Dreamweaver, and my good friend Mike ended up finishing up the feature (after it was killed, then brought back, then killed again, went on tour with the Stones, then finally revived.).

On the Dreamweaver side, we astutely decided not to support these new fangled menus, but still allowed the old kind to be created. This, of course, was heralded as a “Great Idea” by our advisors. No, just kidding, they hated it and called us names. Being the agile company that we were, we quickly had lots of emergency meetings and promptly decided not to do anything. That’s how Dreamweaver 8 shipped.

After Dreamweaver 8 shipped I left the company, and my involvement with those accursed menus ended.

Of course, none of this helps those of you suckered into using these menus. So for your benefit, I’ll now tell you how to fix the mm_menu.js. Follow these simple instructions:

1. Acquire one (1) shotgun. Loaded, preferably.
2. Acquire one (1) shovel.
3. Pump mm_menu.js full of buckshot until you feel better.
4. Repeat Step 3 as necessary or desired.
5. With the shovel, dig a hole.
6. Dump the remains of mm_menu.js into the hole.

If you’re confused on how to shoot an electronic file, I would suggest printing it out and shooting the printout. Sure, you could shoot the real thing off the hard drive, but you might have trouble determining if you hit the actual sectors the file resides on. Also, there might be economic and/or legal repercussions if you shot the hard drive.

So don’t use mm_menu or fw_menu. Go find one of the many HTML/CSS menus that are out there. Some are even free. You could even go buy one off Al Sparber. Tell him I sent you. For the number of people I’ve driven to his door by agreeing to maintain the JavaScript menus, he ought to give you some sort of discount.

Or perhaps he would just laugh maniacally at you and double the price.

I got an IM from an acquaintance today. He works for Apple these days and was asking me if I was interested in a job. It would involve me moving back to California, but I would get to work for the Mothership.

I told him no, there’s only one reason why I’d move back to California at this point.

Although I wasn’t interested in the offer, its always nice to hear things like this. Its good to know someone’s keeping you in mind, and it definitely helps the ‘ol ego.

I’m about three weeks into my new partnership at Order N Development. Its a lot different from my previous job as a full time software engineer at Macromedia.

First, I’m an actual partner, meaning I own a large part of the company. That comes with a lot more responsibility. I have to fill out a lot more paperwork and just in general do a lot of non-engineering tasks. Expense reports, reading contracts, making bids, and so on. Of course, the fact that there only four of us influences this too.

There’s a lot more multitasking involved. For example, I’ve already written up a spec for a potential client, hammered out a rough schedule for another client, reviewed a couple of contracts from potential clients, and brainstormed ideas for our own product. Oh, and somewhere in there I did some actual coding on a contract that we already have. Hopefully this is making me more “well-rounded” as opposed to “crazy”.

I have to say, the contracts are the most disturbing part of the whole process. I can deal with generating product ideas, writing specs, architecting a feature, coding it, and debugging it. Contracts are a whole ‘nother story. They aren’t written in code or English, the only written languages I happen to understand. Contracts are written by lawyers with the express intent of trying to pull a fast one on you. The contract is a legal attempt to put all the responsibility on you while removing all responsibility from the client. But that’s not clearly stated, its written in legalese so you have to spend $400 paying another lawyer to tell you how screwed you really are. A good measure of screwedness appears to be how hard the lawyer is laughing when he hands the contract back to you.

I’d go into specifics, but a lot of contracts say we’re not allowed to mention the client’s name without their express written consent. I understand that the clients are trying to protect their name, but come on. I just did a bunch of work and I’d like to be able to tell people about it. I’ll admit that telling people “I can’t tell you who I’m working for” sounds all cool and mysterious, but it doesn’t really seem to bring in more contracts.

The other scary part is the money doesn’t come in regularly. Well, since we’re working several contracts right now, it kind of does, but nothing is guaranteed. I don’t draw a salary; I just get money when the company actually makes money. The flip side is I’m not limited in how much money I can make. And that’s kind of cool.

One of the things I am enjoying is ability to freely think of product ideas. What’s so “free” about it is that I own any idea that I come up with. Yep. I’m not sure how many people would want a hamster powered beanie, but that’s my idea, and I get to keep it. Seriously though, knowing that I get to keep any idea I generate is a pretty liberating feeling. It also makes the whole brainstorming process a lot more fun. I’m not trying to come up with an idea to make some large corporation another $100 million, I’m trying to come up with an idea that I’d like to work on and that I’m interested in.

And that’s my goal: work on something that interests me.

I’m convinced it is impossible for a Mac engineer to be happy at a large company. It simply can’t work; it is fundamentally flawed.

For the past 5 years I’ve worked for Macromedia as “the Mac guy” on various projects. I started out on Fireworks for a few cycles before moving on to Dreamweaver. My job as “the Mac guy” was to maintain the Mac porting layer, write any significant Mac specific code, fix Mac specific bugs, help the other engineers get stuff working on the Mac, and in general handle anything relating to the Mac. For most part, I was the only Mac guy on the team.

When I first started at Macromedia, working for a well known company on a pretty well known product was an attractive proposition. People would know what I did, and lots of people would see and enjoy the fruits of my labor. I could influence an important product to be more Mac friendly. To me my greatest asset to the team was helping ship a great Mac product. Unfortunately I personally feel that I’ve never shipped a great Mac product. Fireworks was pretty good and Dreamweaver can only be described as “adequate.” Neither lived up to my expectations.

I began examining myself and the development process to figure out what went wrong to cause the Mac product to not live up to my expectations. It wasn’t a lack of observation; I knew what was holding us up. It wasn’t a lack of knowledge; I knew how to fix all the various problems. It was a matter of resources. I wasn’t given enough time to fix all the problems or add all the enhancements we needed. Furthermore I became increasingly aware that I was doing the job of two people, and we really needed at least two Mac engineers.

But the real problem wasn’t resources; it was economics. Both Fireworks and Dreamweaver are cross platform products. They run both on Windows and Mac. I’m not sure what the exact platform splits are, but the Windows product definitely sells more than the Mac product. Therefore it makes sense that the company invests more in that platform since it yields better results. It only makes sense to invest in the Mac platform so that the investment is lower than the returns. In this case, that apparently means only having one Mac engineer per team.

Its hard for me to fault Macromedia. Their decision makes perfect business sense. But it doesn’t make sense for me personally. My goal isn’t to make as much money as possible; I just want to write some software that I can be proud of, for the platform that I enjoy. Oh, and make enough money that I can eat.

My point is Mac engineers can’t be happy working for a large company that builds cross platform products. The goals of the engineer and the company contradict each other. The company wants to invest as little as possible into the Mac platform, while the engineer will want to invest as much as possible [1]. The engineer will end up stressed out, with no free time, a substandard Mac product, and a lot of frustration .

At the beginning I thought I could influence Macromedia to spend more money and time on the Mac product. After a while I realized that wasn’t in their best interest. My second idea was to try to do as much as I could personally. That had a small effect when I worked on Fireworks because the project was small enough and well designed enough. But when I arrived on Dreamweaver I realized that the project was too huge for me to make a difference alone. Unless the company decided to devote more resources I was only go to burn myself out. As I stated before, it wasn’t in Macromedia’s best interest to add more resources.

This is the reason I’m leaving Macromedia. It is a losing fight that I can’t win. Continuing there would only serve to burn me out even more. Of course, this begs the question: if not work for Macromedia, who? Given most large companies that have Mac products would be in the same boat as Macromedia, that didn’t leave many options. I am convinced the only way to ensure that my and the company’s goals align is to either own the company or work for a company that only makes Mac products. To that end, I am joining Order N Development.

I realize this post might sound like a whiney “I can’t win so I’m taking my ball and going home” rant. But its not. I’m saying I can win. I just have to play for a different team.

[1] The only contrary example to this is the Microsoft Mac Business Unit. Although Microsoft takes a lot of abuse from the Mac community, as far as I’m concerned they’re the only large company that has gotten it right. The Mac products are split out into their own business unit and can focus on making on a great Mac product.