Most likely the name Charles Darwin rings a bell somewhere in your memory – perhaps from your high school biology. He was an English Biologist best known for his theory of natural selection. As a computing professional, I do share an appreciation for his approach to problem-solving through classification. I would like to draw similarities between this concept as it relates to software development. Classification provides a frame of reference and allows us to reason about our applications in a broader sense. This is exactly what a good software architecture aims for.
Software architecture is concerned with drawing boundaries and crafting relations among them. In other words, each block of code is carefully be placed within a bounded area. Moreover, these areas are designated based on their problem categorization. So, in the end, we are really dealing with a categorization problem and providing facilities to address specific sub-problems within those categories. Important to note here is that other fields, such as Mathematics, tend to have a similar approach whereas problems are addressed through a certain frame of reference. For instance, we can reason through a given problem as an Algebraic problem or Geometric problem and so forth. A frame of reference guides our decisions based on existing knowledge in that domain and provided facilities in our infrastructure.
A good architecture facilitates greater reusability by providing clean categorization – an abstraction of some sort. The further apart components are, the less likely they share any reusable code. The opposite can be said for components in close proximity. This is even more so for items placed in a similar category. What does this all mean? We address the general problem first, therefore providing facilities to describe our specific needs. Thus, categories emerge as more general problems are solved, and patterns are forged. So what problems are you solving – category? What other problems are you familiar with in that category? Can your problem be framed in a different category? It all boils down to classification and your system should be expressive in terms of the types of problems it addresses.
Top comments (1)
I like the suggestion to ask "Can your problem be framed in a different category?" Sometimes we get stuck in a rut of our own making, going round in circles of thought in a single problem category (a recent one for me: how to manage user accounts and provide SSO across services), when you arrive back where you started for the second time... look for escape routes, start from a new perspective, question the business needs / UX, and you may find another way that solves the right problem for more people (my solution: by /not/ managing user accounts at all, instead federate with customers existing IAM platforms - less work all round, better UX :)