Taking Responsibility for Architecture

- 7 mins

I recently had a conversation with my boss that made me rethink my approach to application development. The conversation went roughly like this:

Me: On a couple of occasions recently, I’ve implemented something only to find I could have made use of existing logic in the codebase. Is there something missing from my approach to navigating a project?

Boss: I’ve trained myself to find and understand the architectural context surrounding an area where I want to make a change before I start adding a new feature.

That was it, more or less. But it was enough to make me realize that I haven’t been thinking consciously about a certain category of architectural decisions required when working as a software developer.

Here is roughly how I had handled things previously:

There is a problem with the above—I’ve introduced a flawed distinction between ‘project setup’ and ‘domain logic’.

Historically, there are a couple of reasons I think I did this:

The basic problems with these:

All these shortcomings were manifesting themselves in a few ways:


When anything outside of ‘my code’ broke, I would often just look for similar stacktraces on stack overflow to find my answer, and because I work in Javascript, this usually worked. But it meant that my application’s infrastructure remained a black box to me, and that I quickly resorted to trying random things when stackoverflow didn’t help me.


I found I was much better at cleaning up other people’s code than I was at writing my own from scratch (because pretty much all non-trivial features require some understanding of architecture, but refactoring often doesn’t). I was also running into the problem from the start of this post; because I didn’t understand architecture very well, I was failing to find the existing architectural intent in code that was already there.

Side Projects

Where are my side-projects? I mainly spend my spare time learning new languages and paradigms, which is interesting enough, but it seems strange that I’m not actually building anything substantial with them….

A Remedy

There is a fix to all this, and I think it could almost have worked for me even as a novice coder (although it probably made better sense for my career to wait until now to make this change). It requires a fundamental shift in your attitude to an application through building the following skills:

(Basically, not using tutorials or big web frameworks to bootstrap your application.)

A community already exists with these kinds of values (although I don’t think they state them explicitly), and it is the clojure community.

Frameworks are noticeably absent from the clojure world, as clojurists are into ‘decomplecting’ things—which roughly means building small units of code united by a single concept—and combining them together on a project-specific basis.

This means the clojure community can help us with point two on my ‘remedy’ list: debugging conflicts between different libraries.

This youtube video by Stuart Halloway contains several helpful pointers that made me realize how sub-par my own debugging has been. Here’s a short summary of the content in my own words:

Write down all of the below:


When building hypotheses:

Following this advice actually involves substantial changes to my current debugging workflow—no more blindly searching for the error message online, no more trying something before formulating a hypothesis just because it’s easy, and no more limiting the possible problem domain to the area of the code that I understand best!

I’ll be following these steps rigorously to improve my debugging ability from now on.

Using clojure can also build some of the muscle for addressing point three on my list (debugging and potentially fixing open source libraries). Handling ‘point two’ situations will involve reading a lot of source code and learning about how the libraries you’re using are built.

The big gap for me is point one. I’m aware that application design isn’t the responsibility of a particular language community, but it would be helpful to have pointers towards books dealing with architecture, in much the same way as the clojure site recommends books on the language itself.

And in an ideal world, resources on this topic would exist that couple architecture with advice on how to navigate a diverse ecosystem like clojure’s and pick the correct libraries to serve as your application’s building blocks.

In my experience, these are two closely related areas that require too much domain specific knowledge for a beginner to teach themselves without some guidance. I suspect the need for this skillset and the current lack of readily available guidance is the main reason Clojure has a reputation for not being beginner friendly.

The best resource I’ve found for this so far is Dimitri Sotnikov’s luminus micro-framework and accompanying book—and it is very helpful—but it is still a tutorial that doesn’t teach you how to pick out libraries by yourself.

Given all this, my goal moving forwards is to build a small side-project in clojure, taking luminus as my base. I think it will help me build at least 2/3rds of the muscles that I’ve been neglecting up to this point, and with a bit of luck it will give me some of the domain-specific knowledge I need to begin tackling the other 1/3 as well.

Alex Chalk

Alex Chalk

Software Developer | Node/JS at Work | Haskell/TLA+ in Spare Time | Employed at Busbud

comments powered by Disqus
rss facebook twitter github gitlab youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora