Finally I am releasing the code I presented for code analyses at EmacsConf2020. I will publish posts and code weekly, and you can find everything here.

Good software comes from understanding what clients want and code that down for them effectively. Although the first part requires skill, the second part is often less effective than I would like.

When I want to modify an existing code base, typically I need to understand why others designed things in a certain way, refactor that, and then add my stuff in. Often this process is difficult because:

• code design has hidden assumptions
• no documentation
• maybe tests
• nobody around knows anything about that code

So between requirement elicitation meetings and careful investigation ¹ to guess what the code is doing... decision fatigue again, help!

This is really a pain because sometimes we ourselves make the situation worst without realizing in our development effort. Over time this accumulating "imperfections" slow us down dramatically, a phenomenon known as tech debt.

Even worse, there a lot of "we" in a software project: so the more everybody rushes for adding their feature, the more the aggregated code base becomes cryptic.

If only I could get some guidance in how to deal with this ever increasing complexity!

And luckily there is a way! The secret iiiisssss... in your .git directory.

This year I read Your Code as a Crime Scene by Adam Tornhill (and his follow up book), and I got enlightened: Git (or any version control system) really is our history keeper. In general we can learn much more from history than we actually try to do (e.g., in human history a pandemic has often run three contagion waves, the second being the toughest...). Learning from history applies to software too!

What if I can see where my technical debt is accumulating? What if I can get an alert when I unconsciously accumulate it? And what if Emacs can tell me that while I am coding?!? Just dig and interpret your git data with a bit of Elisp :)

In my recent talk at EmacsConf2020 I show what I got so far bringing Adam's analyses to Emacs.

My aim is much more ambitious though: I want my preferred OS editor to become my compass pointing towards high quality and effective text editing! (Note here I say text, not code: I am certain writers can benefit of this too. And I will put effort into testing this idea out soon!!)

For now, I am slowly integrating the results of these analyses to actively enhance my development.

Think of Emacs telling me who I can ask for help, or what files I should modify after this according to what other did in the past, or even warn me if a commit as added too much complexity to the code, remembering me to refactor.

Again I want Emacs to point me towards a more effective way of developing without becoming an obstacle.

I have finally started a repository here: https://github.com/ag91/code-compass. I will extend this with what I have developed so far at a (hopefully) weekly pace so that I can explain with a blog post what the analysis is about and how I use it.

Note that I will initially support Git version control only, but I am open to PR and contributions. Also I would love to hear feedback and ideas to make this more useful for you. I am already investigating some suggestions I got during EmacsConf2020 (which was a wonderful and chill event, by the way).

I hope this Emacs extension will be useful to you too!

Next week: how to find technical debt and design decay at a glance with hotspots!

This has been mostly an announcement post, because for now I have only defined the dependencies needed for code-compass. So stay tuned for next week, in which we will get into one of the core insights you can get from your git history.