"The problem with most tools is not that they don't work - it's that they solve the wrong problem." - Gerald Weinberg

We were one decision away from pulling in D3 or ECharts for a CodeScene-style visualisations; treemaps, chord diagrams, knowledge maps. That seemed like an obvious move. Everyone does interactive charts in JavaScript.

Stopping and asking: "why does everyone do charts in JavaScript?" changed the direction.

Round trips to a remote server are expensive. You push layout logic to the client to avoid latency. That's the premise the entire client-side charting ecosystem is built on.

In Elixir Desktop, the Phoenix LiveView server and the WebView client live in the same OS process. There is no network. Round-trip latency is effectively zero. The problem JavaScript charting solves just isn't a problem we need to solve here.

This thought flipped our decision completely. Pure Elixir SVG. Layout algorithms as pure functions - fully unit testable, no browser required. An ops-as-data pipeline: the layout module produces a list of plain Elixir structs, a shared renderer consumes that list and produces SVG, and the WebView paints what it's given. Zero JavaScript in the rendering path.

The renderer itself ships as an extension - a standalone OTP app that any plugin can load. If something better comes along, we can simply swap one extension. The code analysis plugin, the delivery flow plugin, every future plugin benefits without touching their own code.

The point isn't "Elixir over JavaScript." The point is that assumptions travel with tools. Client-side rendering is the right answer to a specific problem. Check whether that problem exists in your context before you inherit the complexity.

Ours didn't.

Always challenge the assumption you're making. ;-)

"The best way to predict the future is to create it." – Peter Drucker

Well, I did it. After months of deliberation, the PoC is being rebuilt in the awesome Elixir Desktop project created by Dominic Letz (https://github.com/elixir-desktop). And honestly? It feels right.

The April post from last year hinted at this. The "yuck feeling" with JavaScript wasn't going away, and the more I dug into Elixir and OTP, the more I realized I wasn't just picking a language - I was picking a foundation. Supervision trees, fault tolerance, hot code reloading, pattern matching... these aren't nice-to-haves for a plugin-based desktop application. They're the right tools for the job.

The plugin system is where this really shines. In Electron, I was fighting the framework to get clean boundaries. In Elixir, I have proper behaviours defining the plugin contract, a standalone SDK, and OTP supervisors watching over plugin processes. A plugin crashes? The system recovers. No drama. "Let it crash" isn't just a motto, it's genuinely how this thing works now.

Phoenix LiveView handles the UI, and I'll admit - I didn't expect a server-rendered reactive framework to feel this natural in a desktop app. But it does. The Hexagonal Architecture I was striving for in JavaScript just falls into place here. Ports, adapters, bounded contexts - Elixir practically nudges you in that direction.

Is it perfect? No. The ecosystem is smaller, the desktop library is still maturing, and I'm forking dependencies to get features I need. But I'd rather build on a solid foundation and fill in gaps than build on sand with all the convenience in the world.

The Electron PoC served its purpose. It validated the idea. Now it's time to build it properly.

"In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing." – Theodore Roosevelt

Some decisions have a lasting impact. Others are easily reversible. When faced with easily reversible decisions, make them quick! When not so simple to change, go slow, consider the impact of having to change them.

The PoC so far has been all JavaScript, Electron has matured and by sticking to vanilla JS, I've dodged a few bullets as far as dependencies go. However, I have a few challenges with JavaScript that I'm not sure will be easily overcome. The plugins / plugin system, while still simple, suffices but its not a full or 'proper' system yet. Licensing and Anti-Piracy is more of a challenge due to the scripting language (vs. a compiled language), and there are a few options here. Lastly, but not a small thing, I get a 'yuck' feeling when coding JavaScript compared to other languages, especially compared to things like Elixir.

I've been playing around with Elixir for about 9 months now, the last few more dedicated to really understanding the underlying Erlang language and OTP. I really like it. Recently (about a month ago), I stumbled across the Elixir Desktop project. Phoenix/LiveView in a desktop application? Hmmmmmm... Compiled code, the BEAM, Functional Programming, in a desktop application ... The distributed and concurrent nature of Elixir is wasted (for now) in this, but I don't know where this product will end up, so is it a bad thing to have the option to support some concurrency if I ever need it?

I may just need to build out a second PoC in Elixir Desktop to see where it takes me. I'm unsure but have a pretty good feeling that it's possible to have a more robust plugin system in Elixir than JS will allow for and the licensing concerns may be simpler in Elixir (I'm unsure).

Wish me luck!

"You can have everything you want in life if you just help enough people get what they want in life." – Zig Ziglar

Well this has been an extra interesting week. I'm trying to pull another dev in to work with me on this product. He's smart and has a great way of thinking and looking at things and a rock solid work ethic.

Any skill gaps, We can help each other fill in, we can learn together.

The bottom line is that I need help, I need interaction, I need another set of eyeballs and a second brain. The challenge is always finding good people.

"AI code generation is amazing. Now we have infinite bad code at the speed of light!" – The CTO of 'It Works On My Machine Inc.'

Co-coding (or "Vibe Coding") with AI is closer to baby sitting a drunk toddler that can read and write code ... poorly. Don't believe the hype folks, AI generated code is mostly trash.

Where I have found some use in tools like 'Windsurf', is in having the AI analyze the project (since it can see the whole workspace) and tell me what it thinks needs to improve. I could do without all the positive placating these AI do, but its part-in-parcel for making people believe they are 'thinking'.

It's still wrong (A LOT). But it does feel like an extra set of eyes. Such a strange world, especially since I understand how LLMs actually work and that there is zero 'intelligence' in any of this stuff. Just the ability to correctly select the next word.

"Quality is free, but only to those who are willing to pay heavily for it." – DeMarco and Lister

A new year and a ton to be grateful for ... I've got the Build Box configured as a GitHub actions runner, automated building and testing is critical in my opinion.

Automated e2e tests and feature tests with Playwright and Cucumber have been layered in along with the unit and integration tests. They (the UI tests) are slow as expected, and pausing to write step definitions is a bit of a pain, but when I break something (and I break lots of things, often), I'm aware of it.

SonarQube for the static code analysis, and the linter in my VS Code save me from myself and unnecessary technical debt as I code, so you could say "I'm totally eating my own dog-food" in the development of this project.

For all the pain, I have high confidence in the quality i'm building. Effort - Incredibly high, Value - Totally worth it.

It was a good holiday season. Here's to an amazing 2025!

"Almost everything will work again if you unplug it for a few minutes... Including you." – Anne Lamott

Winding down for the holidays ... I intend to unplug longer than just a few minutes, but i'm a workaholic so we will see how far I get with that.

I need to get a few things done for this project over the holidays, but mostly IaC and automation type things. I still need to do a bit of research on how to properly package electron apps and I still need to figure out the best way to test this thing for *nix and Winblows platforms.

The goal is to hit MVP and get some real world testing and feedback in early to mid 2025. The feedback will help planning out the future direction.

A short update this month, but at any rate, I wish you all (if anyone is reading this) a very good yule and happy holiday season for 2024. May you be safe and surrounded by loved ones.

"Software development is like gardening… It is never finished; you must constantly prune, refactor, and adapt." – Kent Beck

Continuous refactoring is the way. It's amazing how quickly the main renderer in this electron app can get unwieldily and out of control. I try to keep a clear separation of concerns, but let's be honest, this is a balancing act, especially in a PoC / Prototype. I can only let myself write cruft for so long before I start to feel the effects of it and have to cleanup.

I resonate with Kent and have since I was pointed at his eXtreme programming book, back sometime around 2002. His latest book "Tidy First?" is a nice fresh take on how small refactoring can make a world of difference for future me.

I feel like the trick is knowing where to stop and resume 'building'. I tend to tangent and get pulled into the weeds. Anyone else feel like this? What do you do to keep yourself building at a good pace and balancing that with the never ending but necessary refactoring?

"Create your application to work without either a UI or a database so you can run automated regression-tests against it" – Alistair Cockburn

I've been focusing on the Plugin/Framework architecture for this. I'm a fan of Hexagonal Architecture and loose coupling. It's just more sane.

Fun aside: I've been architecting in a loose 'ports and adapters' pattern since long before I heard of Alistair Cockburn, back in 2003 - 2005 the flagship product we built at v.1 labs used the same patterns.

Since this is an electron application (and i've still managed to keep most of the dependencies out), clean boundaries on what a plugin should be responsible for and a balance is necessary.

But it is a bit of a struggle. I'm coding on my own here, so I don't have the amazing discussions and dialogue that you typically get with a team. I overthink a lot. Imposter Syndrome is real.

"Everybody should learn to program a computer because it teaches you how to think." – Steve Jobs

I've "borrowed" another great idea from Adam Tornhill, representing file coupling with a circular ribbon graph, also known as a chord diagram.

I feel like this diagram is one of the better ways to simply and visually summarizes how different files are coupled together.

The graph is generated by looking specifically at files that are most often edited together in the same commits. This can be useful in uncovering architectural issues as they start to arise and code smells (like Class Envy) as they start to show up.

The hope is that this will signal someone to take a second look at what otherwise will become an accepted bit of tact knowledge, trapped in the mind of one or (hopefully) more developers' heads.

As you can see, I'm tinkering with visualizations of the data that companion can get out of a git repository. (note that this is an experimental rendering with d3, not all information has been rendered)

"First... solve the problem. Then! write the code." – John Johnson

The main problem I’m solving for is "Ensuring that teams have useful information they can use, presented in a clear way to help them make decisions about the best thing to do next." This is really the primary value proposition of this application. Visualizing the way work is actually progressing.

I find this a little fascinating because the problem being solved is related to the people doing the work and how they might approach that work differently if they could just see through a different lens. But the benefactor and my target demographic is the business. It's a little bit like the consultant’s dilemma.

The second problem that I’m trying to solve is through simple observations based on the evidence of how the work is getting done, not in the 'here is a burn down chart' way, but in a 'this is what’s true right now' way and here are some suggestions. This is where my brain feels like some machine learning (incorrectly hyped as AI) would be useful.

I'll have to think more about building a small language model (SLM) that can identify common patterns and make simple suggestions. There is no shortage of tools that determining the health of the products we build; the challenge seems to be making them simple.

"Validation is much more valuable than ideas." – Erika Hall

Ideas are great and all, but they must be tested and validated with actual users to ensure they provide real value.

While I was at Agile Coach Camp Canada last month, I did a short talk on the usefulness of visualizing how teams are doing through Behavioural Code Analysis and the attendees we all pretty engaged with the conversation.

From a Coaching standpoint where the current Kool-Aid is all about tearing down the A word, time is of the essence and timing can be everything.

I suggested that I was working on something (this), and that we should follow up in a year. Feeling like the idea has been vetted and validated by my peers, as well as one of my customer segments (Coaches), I'm happily (although slowly) moving this forward with a loose timeline in my head.

I think a few of the attendees may have even been a little excited at the prospect of delivering even more measurable value to their clients.

Many thanks to all the Agile/Technical Coaches who participated in the discussion!

"Good Artists copy; great Artists steal!" - Pablo Picasso

CodeScene, from one of my favorite authors on the subject of Behavioural Code Analysis (Adam Tornhill) has some pretty nice looking elements figured out for a bunch of what I want this tool to provide to teams. That's what you see in the image above, (the 'Code Scene' portfolio view).

I'm still thinking through this product idea and there is lots to learn as I go, so you will have to bear with me while I let my mud settle. I seem to be averaging posts to this micro-blog on a monthly basis, which is okay, I may step it up to weekly though. Considering I am working on this several evenings a week and every weekend.

I'm leaning a little into TypeScript since it forces me to write cleaner code. I'm still resisting react however and I'm quite perplexed with GitHub. They recommend their Octokit library for node based JS projects and yet the GitHub Desktop client (itself, an Electron application) doesn't use it.

Why recommend something you don't consume yourself? Not to mention getting basic commit details takes multiple calls anyway in Octokit. If I must make multiple calls, I may just be smarter to roll my own REST Client for the GitHub API.

Stay Tuned!

Doing minimal "planning" and taking action.

"Plans are useless, but planning is indispensable." - Dwight D. Eisenhower

Moving ahead, I've been thinking a fair bit on this, and have had a few different thoughts about what languages, environments and frameworks I do, and do not want to be coupled too. My initial thought was that this application should be available on all devices and platforms. But that's YAGNI for the target demographic. At least for now.

The customer segment I'm looking to solve for and the specific problem I'm trying to solve only requires this to be a desktop application. macOS, Windows and Linux (sorry mobile / tablet people). This constraint helps. Flutter and dart could still be a contender but is it necessary?

What I DO know is that I don't know where this will go in the future, what other platforms could be integrated or have a similar need to generate useful metrics? How will this change? No clue, but I do know that time will tell the tale (it always does), maybe I'm about to step into a minefield, but I've opted for Electron (Node) and a pure JavaScript (ECMA Script) approach over the myriads of JavaScript frameworks.

I'm not prepared to take on that additional technical debt from the get-go. One of the deciding factors in picking Electron is that I use VS Code often and its quick. It supports the notion of 'extensions' (plugins) and that's exactly the right direction given I don't know what I don't know.

Wish me luck! and May the fourth be with us all!

Companion - The Inception of an Idea

Everything starts as a simple idea (usually to ease some type of pain) and Companion is no exception. As a Technical Agile Coach working in a big enterprise environment, I was often the bottleneck in generating some valuable reports for teams thanks to the amazing work Mike Bowler has done with his Jira Export tool.

The challenge is that you needed to be at least partially technical to get this tooling to run and generate the reports, but the data these reports hold is honestly, very highly valuable for teams working in Scrum, Kanban or ScrumBan (ish) frameworks using Jira.

Being the kind of geek I am, I asked myself a simple question. What would this look like if it was a standalone and contained application that anyone could use? ... You know, so I wasn't needed to generate these very valuable and detailed reports.

This simple idea quickly started to get away on me ... What if it was visually configured? What if I could easily specify the time range for the reports? What if I incorporated some of the 'Behavioural Code Analysis' I do with teams into this same tool? What other integrations would be useful? What if ... and off I go!

This page will serve as a 'high-level' change-log and micro development blog as we build out this tool. Check back often for updates or Sign-up and we will let you know when we have added to this (or the documentation) pages.