Thinking Inside a Bigger Box

Unstructured picture

I recently started on a new project. Looking over the code base, I saw the familiar structure of many projects: Definitions of classes goes here, persistence logic goes over there, interfaces to the persistence logic goes this other place, code for transforming from one structure to another in yet another place and so on. This is common, neat, and unfortunate.

As an exercise to understand the architecture of this system, I decided to add some new functionality: Displaying some data to the user. I haven’t worked this task oriented with this sort of system before, and so I hadn’t noticed just how extremely clumsy the common structure of these projects is to work with. In order to create the functionality, I had to navigate to around 10 different directories. In each directory, I had to work with one single file, and ignore the tens of files around it with similar names.

Tidied picture

While watching a few videos from the TED-conference, it finally struck me: We often think that the job of software architecture is to tidy things up, so that things with the same attributes are sorted into neat piles. Too often, the attribute that we chose as the basis for our organization is an incidental, inconsequential one.

Here’s how to tidy up art:

Maybe this is not how we should organize our software system? What do you think?

• The pictures are from Ursus Wehrli’s book Tidying up art. Be sure to check out his 15 minute talk from the TED-conference
• This subject was also discussed in my blog post on Packaging by features, rather than layer.