When it comes to human-computer interaction (HCI), one of the major failings is that we are constrained by what we see. That is, we have difficulty conceiving of things existing beyond the boundaries of our visual feedback (or more commonly know as “out of sight, out of mind”). This is not necessarily a failing of the HCI discipline, but perhaps one of the human species, and our lack of attention to practicing the conceptualisation of things we cannot see.

Similar conceptualisation issues arise with respect to software development, whereby developers start with a small project and, over time, it becomes a large one. Unfortunately many developers don’t perceive this change in size and scope, and continue treating the project as small.

For example. let’s say my example project Acme 1.0 has a scale of 1 (relative to other projects). Now lets say that Acme 2.0 has twice the functionality of Acme 1.0, however as it is treated no differently, still retains a scale of 1. Now the issue here is that I have squeezed twice as much functionality into the same “conceptual” project size. Eventually this project is going to implode on itself due to it’s density.

The solution to this problem is to expand the project universe, conceptually if need be, but there should be a mindset of expansion with each major feature addition. Modularity is one way to deal with project expansion, in that it is much easier to deal with the expansion of smaller sub-projects. Modularity also sews the seeds to be able to further split projects into smaller projects when they become too dense.

Some nice analogies might evolve from such a view of projection expansion. Perhaps viewed as an expanding universe, where projects with tighter coupling group into constellations, projects may form just like stars and planets, i.e. coalescing of ephemeral code. But analogies need to make sense, rather than just sound cool. Perhaps a topic for exploration nonetheless.