The Global Game Jam 2015 is coming up next weekend, and I plan to attend in Tempe, AZ. I’ve spent some time diving deeply into JS, Redis, and Python (as well as Python for customer work) to be ready for the Jam. I’ve been working primarily with what is known as architecture.

What is architecture? Part of the challenge of software as a craft is the continuous renaming of things. I’ll define what I mean to avoid confusion.

The most basic: architecture provides the structure or form to which the developed software is attached.

Most development work is writing code to accomplish things. For instance, code to move a monster in a video game. That code uses logic, processes inputs, causes actions which reflect in changes to the program (changes in state) and the player sees an update to the screen as the game progresses.

How does the screen refresh? Probably a game engine such as Unity 3D for instance. That is part of the architecture.

To the developers of Unity 3D the product isn’t their architecture; they are writing code to accomplish things. Their architecture contains a variety of lower level aspects and tools. To the authors of those tools …

Architectures are tools … and someone writes them. In large companies there are teams who work to improve architecture so that the other teams can be more productive. One team’s architecture is another team’s code.

The main parts of architecture in software are frameworks, libraries, and the tools that make up the development toolchain. All of these are reusable. An example of tools are compilers, code generators, and version control systems. Of course, the tools are just code too.

Frameworks differ from libraries in that frameworks call the team’s code, and the team’s code calls library code. Both frameworks and libraries are made up of code that is included in the release.

Often during development a team extends a framework or library in ways that allow them to more easily use both. Ideally, these additions would then be returned to the framework and library maintainers so that the architecture itself improves for all the consumers.  Too often, though, the project team tries to maintain these changes along with their project code, which causes their workload to increase instead of decrease.

The increase in code is caused by a lack of abstraction. By not abstracting the architecture code out of the application code the more specific application code is entangled (less cohesive, more tightly coupled) with the more generic framework and library code. This works to the detriment of all the code. Application code must be clearly written to be maintained as the user requirements change. The architecture code needs to be clearly written to be maintained as the application writers needs change. Two different sources of change, mixed together.

The tools are often not regarded as part of the architecture. When in Hong Kong, I saw many buildings being worked on (painted, new windows, etc.) and almost without exception all the scaffolds holding the workers were bamboo poles lashed together. At the end of the project, they took down their scaffolding for re-use on their next project. These bamboo poles were tools in their project that allowed the project to complete (or in software terms, that enabled delivery). Thus, the tools are as important to the architecture as the parts delivered.

Tool makers on a project always have a certain tension. There’s an old question in software: should I spend a week to do a job, or spend a week to make a tool that does the job in an instant?

If the job done is common enough that you’ll need to do something “close” more than once the tool pays off handsomely. If the tool is only used once then it was probably a waste to use it.

There are many exceptional tools that are rarely considered though the mainstream tools are commonly known.

Mainstream programming language interpreters and compilers have dramatically reduced the work done by developers. I guess I show my age, but I recall assemblers, monitors, and hex/octal coding. One can truly write anything in raw machine language (or with a macro assembler) but … why?

Less common, Domain Specific Languages (DSL) are often spoken of but I rarely see them used as effectively as they can be. In fact, one of the tricks I use to spare myself pain on projects is to invent one (or more) languages just for that project to let me state things more easily. These languages will generally not be useful on other projects (if they were, they’d become general-purpose and not domain specific) but they are tremendously useful to later versions of the project’s deliverables.

Frameworks, libraries, and tools make up the architecture for every project, from a simple script to a full application (and to operating systems, device drivers, and any other deliverable out there).

After every project completes, part of the post-mortem must be to refactor out from the application code all that should become part of the architecture. Even if it’s not sent back to the maintainers it should become part of the organization’s reusable code foundation. Then your organization will benefit from each project more than once.

And that is an awesome type of force multiplication for fun and especially for profit!

For the Game Jam I’ll bring in a very distinctive architecture. By the end of the Jam I’ll have a DSL (or two) for whatever the game needs and a new round of additions to the architecture as well.

Keep the Light!