Bus Factor

The Bus Factor for a project is the number of people that if hit by a bus (or equivalent leave) would break a project.

In an ideal situation there are sufficient runbooks and documentation for a project to continue should all the team members leave. This is frequently not the case.

Pairing can help reduce the Bus Factor. Two people have context on most things. This can still go wrong with the minimum effective team size (3). METS allows for one to be on holiday, one to be sick and still have someone to continue some form of progress. The downside is that someone will not be pairing (or the team can only mob on a single item).

You can’t eliminate the Bus Factor but need to reduce it. If anyone has too much information in their heads then they need to start actively writing down more than they would normally do. This means carefully documenting how to do anything that only they need to know.

This can seem counterproductive if having special knowledge makes you feel special. However being unreplaceable also means being unpromotable as the essential knowledge that you hoard will become a burden.

How big is your projects Bus Factor?

JavaScript Options

JavaScript is currently the default for interaction on web pages. Just because the page loads JavaScript it does not limit you to using JavaScript to write it.

The simple option is just to write JavaScript. This works an is the common approach.

The next step is to use Babel to transpile various extensions into JavaScript. This allows the use of language features that the browsers don’t yet support. Hopefully the near future loss of support of Internet Explorer 11 will allow this process to become easier. This is the typical option for React. This allows non-javascript components to be translated.

The next option is to move to Typescript. This is a backwards compatible language that adds some structure to JavaScript. This makes refactoring easier and adds some type information. This only exists at compile time. This is the technique used by most Angular applications.

There is a further option to move to other languages that compile to JavaScript. Here I am going to consider Elm, but other options exist (PureScript, Gleam). Elm is specifically designed for frontend applications. It’s a strongly typed functional language that makes strong claims about eliminating runtime errors. It has its own model based UI tools. It won’t eliminate logic errors but will work hard to give you it’s famously useful error messages.

Elm uses expressions rather than statements. This means that you always need an else if when you use if. Expressions always return something. It is a compile error to omit this. The language also has strong opinions on tab Vs spaces, as a tab in code whitespace will give a compile error. Lists need to be of a uniform type. Tuples can only have 2 or 3 elements (this constraint will greatly simplify APIs).

Strategic Domain Driven Design

I have recently been helping with a series of discovery workshops. The aim was to make recommendations on the future architecture of the system.

Several of these involved using concepts from DDD. In particular the workshops identified the bounded contexts and built a context map between them. Occasionally we described the entities within them, but these were mostly used to clarify the boundaries between systems.

For strategic analysis the ideas in second half of Evans DDD was of more interest than the first tactical part. Here we didn’t have a greenfield environment, but were trying to find a way to improve a certain part of the process.

The concept of separating the problem space from the solution space helps here. To design a logical architecture requires that the system be described in terms of the problem rather than the (possibly) existing solution. This means there can be no reference to databases, proxies or internal system names.

Living with Hybrid AngularJS/Angular Applications

AngularJS falls out of support at the end of this year. If you still have a sufficiently large AngularJS codebase then a full migration is not an option. There are third party companies that sell support for when the official support ends, if being supported is important.

The only viable option is to move to a Hybrid application mixing AngularJS with Angular. This involves the use of ng-downgrade and ng-upgrade to bridge the boundary between the two.

The first stage of this process is to get the Angular JS app upgraded to the latest version. This can be non-trivial if you have an old codebase.

Early versions of AngularJS used an older proposal for Promises that predates (and is incompatible with) the now standard Promises. This may require the team to learn the differences between old and new Promises.

Modern Angular libraries now use Observables. This is another technique to understand before migrating. Observables allow the consumption of data before it has been fully read. This typically allows pages of data to be consumed. However with an older codebase for the backend then this may not be very useful.

The new libraries assume that the data being supplied is JSON, rather than the XML that older applications used. Early AngularJS projects will probably have a Java backend based upon the technology recommendations of the time.

Angular is also typically written in Typescript rather than JavaScript. This is another learning curve for the development team.

Concurrent Data Processing In Elixir (B4) Part 2

Chapter 1 was about Tasks

Now working on Chapter 2

This implements a Job Control system (with retries) using a GenServer.

This builds a more complex setup for supervisor trees.

This introduces a DynamicSupervisor and then adds transitory supervisors that watch their own jobs (which can then terminate cleanly.

Here is the sample from chapter 2: https://github.com/chriseyre2000/jobber

The important detail here is the use of a Registry, which exposes the underlying ETS (Erlang Term Storage) system used.

Concurrent Data Processing In Elixir (B4)

Now that the book has reached the sent to print stage I am again working through it.

Here is the repo containing the samples from the first chapter:

https://github.com/chriseyre2000/sender

The first chapter works through the simplest solution to concurrency: Tasks.
It starts with a simple slow example and step by step adds more sophistication until you get to have a Task.Supervisor watching the code.

This is one of the more elegant examples of demoing the power and simplicity of Elixir tasks that I have seen.