Never neglect your project's architecture

Martin Fowler of ThoughtWorks began the second morning of OSCON 2015 with a talk about architecture.

Fowler started his talk by defining what architecture means with regard to software. The common definition that people have come to accept is: "the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."

But what really matters here, Fowler said, is that those working on open source projects share a common understanding of what the system is and how it works. This shared understanding among experts leading the project is what really matters.

There is another definition, which says devleopers should decide make architecture decisions early on. Architecture, Fowler argued, is really just a list of decisions that are hard to change. For example, one's choice of programming language is something that's hard to change down the road, so this is a component of architecture on which one must decide early on. All this boils down to architecture being the decisions on "the important stuff."

So why do we care?

We often hear this question regarding our open source projects. People will insist that "we need to put less effort on quality so we can build more features for our next release." The problem with this argument, Fowler said, is that it assumes "quality" is something we can trade off for cost. But who gets to decide that cost?

Architecture is internal quality in software, and is not visible to most users—so why would they want to pay more for something they can't see? Because as time goes on, adding to and enhancing softare becomes more and more difficult, as internals weren't considered early on and weren't kept healthy (learn more about this hypothesis from Martin). Having low internal quality might seem like a win at the time, but high quality ensures that, down the road, we can add more features faster.

I think that we all (those in the room and those reading this who participate in open source communities) have dealt with this type of issue in our projects. I know that I see it all the time when working on Koha. When do you take time to focus on internals, when do you focus on new features—and how do you strike a balance?

This article is part of the OSCON Series for OSCON 2015. OSCON is everything open source—the full stack, with all of the languages, tools, frameworks, and best practices that you use in your work every day. OSCON 2015 will be held July 20-24 in Portland, Oregon.