Extensibility

(from Wikipedia)

… is a system design principle where the implementation takes into consideration future growth…

…the design includes all of the hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure….A good architecture provides the design principles to ensure this—a roadmap for that portion of the road yet to be built…These excess capabilities are not frills, but are necessary for maintainability and for avoiding early obsolescence.

…can also mean that a software system’s behavior is modifiable at runtime, without recompiling or changing the original source code.

—-

This idea is useful when building projects that have iterations or phases. Sometimes the client knows they’re going to want multiple versions of a given project. Realistically though, this happens all the time, even when one is working with little outside influence. An idea doesn’t usually look the same on the screen as it does in our minds or in a script. It needs tweaking and fine-tuning. As designers, we often go through myriad iterations before reaching the final product. Over time, I’ve come to realize ways to save myself future hassle by taking time upfront, at the start of a project, and planning what pieces might change how I can design them to be more flexible and more economic. This ‘brain-time’ early on reduces the ‘oh crap’ time later.

(more…)

I’ve had a lot of people ask me lately about what I consider myself, a designer or a developer. Well, I’m both. It seems to take me by surprise every time I’m asked. Probably because I never planned on being a developer. But now that I do Flash development, I can’t imagine not doing both. The other night I found this great article by Nick Velloff that describes what I do pretty well.