Optimization

When we think/talk about ‘optimization’, we almost always are thinking about Performance.

But, optimization is not inherently about performance, that’s just the main way the concept tends to be applied. Optimization doesn’t mean that you fix bad parts of your code. That has another name; I don’t know what it is, but it isn’t ‘Optimization’. You optimize for something, and you do this by making concessions in some other area of lower priority.

Optimization is about making hard choices. To do something you have to not do another thing. Don’t put yourself in the position of trying to do several things kind of well. Make a choice and optimize for it. You’ll be so much happier.

What got me thinking about this:

This is going to be long, so I’m going to prepend these thoughts with a shorter example that will also be much more clear.

// Begin shorter clearer thoughts

So, for example, back in the old days of web design/development, optimizing images was a Big Deal. I spent a LOT of time trimming images down as far as possible while still maintaining a decent image quality. There were many times where image quality, or image size, had to be reduced in favor of image size. Because back then 50K (that’s K with a K) was a heavy page.

Back then, the conventional wisdom was that if a page didn’t load in four seconds, then people would go someplace else. 50K, four seconds.

And don’t even get me started on IE vs. Netscape Navigator.

Anyway, you can see what I mean about Optimization. It’s not about performance, it’s about making choices between two priorities. Or, better put, it’s about committing to priorities.

Okay, on with the rambling mostly-relevant ‘blog post’:

// End shorter clearer thoughts

I’m an ActionScript developer, which means that sometimes I work with Flash (I know, Flash is finally dead, but I just can’t stop taking jobs that pay money, for some reason). There are some really interesting aspects to developing in Flash, one of which is that it is often completely accessible to other people who are absolutely not developers.

To support an ad hoc workflow between myself and team members who have a different set of skills, I have often written code to encapsulate items that exist in Flash’s library, and then written little adapter sub-systems that let my team mate/s plug various library items into to the larger system via their interaction with the Flash authoring environment.

This is an optimization.

Flash is a very fluid medium with lots of ways to screw yourself up (or be screwed up by other people (other people, I’m looking in your direction…). If you aren’t familiar with how Flash works (i.e. what’s a Timeline, and why can you put code on it?), just trust me that there are nearly infinite points of entry into the logical layer of any given Flash project.

Now – if you are working with a non-logical person, who understands the basic workings of Flash, you may find yourself making compromises in some particular data structure or event flow in order to provide your friend with a way to easily add, modify, or remove items from a particular system by writing very simple code in a frame on a layer in a timeline.

This is, obviously, exactly the situation I found myself in, last week. And as I sighed and shrugged my shoulders and wrote some comments in my code, I realized that I had done this sort of things a lot over the years. And that it’s a good thing (though, can easily creep its way into being a bad thing).

The whole point of code is to solve particular problems. Solving a given set of problems – just in general terms, I mean – necessarily requires you to NOT solve other problems. In some cases the non-solved problems are irrelevant, in some cases they are nearly as relevant as the solved problems.

When a non-solved problem is relevant, that’s when you have to make choices to optimize for the solved problem. It means that you have to make compromises, sometimes uncomfortable compromises, in the way you’re doing things, in order to solve the _actual_ problem domain.

When you optimize to solve a problem, be thoughtful and careful. And document what you’re doing. Write plentiful comments in full sentences – besides being pretty critical for later times, this will almost definitely help you think through exactly what you’re doing and why. Normally, I come up with at least one better solution when I do this, myself.

So…. dang. What was I talking about? Anyway, don’t get stuck insisting on ways of doing things that you have come to believe to be Best Practices. Optimize, as needed – sometimes that means doing some fairly crazy things (in those cases, try to think of a less crazy way to do it and/or write a funny blog post about it).

If you start experimenting with optimization, you’ll likely find that some smart people have already been in your general situation, and have developed some patterns/practices that you can follow and add to your expanding box of best practices.