Any software development project has to manage the upgrade treadmill, especislly if javascript is involved. In any given week you are likely to see a high or critical update. AI has increased the speed that these are discovered and also how to apply the patch.

In order to be able to apply the patch in a reasonable time you need to keep everything relativly updated. Staying on the bleeding edge opens you to supply chain attacks, getting too far behind makes patching risky.

Security checks are now an everyday operation.

You may want to occassonslly check for any part of the system that is more than a year old.

These checks get painful if you have an overgranular set of microservices as this cost must be paid for each service.

The trick is to work out where your sweet spot is for your system. I am for same day for critical, tomorrow for high and Friday for all others.

My current employer has a system for priotitising future work. It includes all kinds of details that are required to quantify the project including leading and lagging metrics.

This is great if you are adapting a system and want to invest in thd highest value item.

This does not work so well if the project is to replace a key feature of a system. We have six months to move to a new API or a major part of the system will stop working.

Now I could spend time constructing such a metric, but that time would be better spent on solving the issue.

This is an article on running elixir tests without a project.

The problem I am trying to solve is to have a true isolated unit test that does not require the entire project to be built. Given a suitably large codebase the tests can take 30+ seconds to start due to rebuilding the world. This is painful if you are only working on something that is isolated from the rest of the system.

The main trick is to use the elixir cli tool to run just what you need without requiring all the heavy details from the project.

This is a project that shows off using this technique.

Even on a trivial project you get some speed ups locally ./first-test.sh was twice as fast as mix test

Competitive Engineering (Gilb 2005) is a dense book that describes an agile process for project management that is different to that typically used by the typical agile manifesto.

This is an older process that tries to replace what would have been described as waterfall development with something practical. The book has a lot of great ideas but is not an easy read. It is especially challenging as most of the book uses a semi-formal language called planguage to define itself. It does not limit itself to software projects.

Lets break the big ideas down in reverse order.

10. Evolutionary Project Management.

The idea here is that you can break any large project down into a series of small steps that each deliver some value. Typically each step should only cost no more ghan 2% of the total budget.

9. Impact Estimation

A technique for comparing design ideas numerically against a fixed set of requirements.

8. Specification Quality Control.

A technique of inspection of documents against defined rules.

7. Design Ideas and Design Engineering

How to find an specify design ideas

6. Resources Budgets and Costs

Resource requirements

5. Scales of measure

A great technique for making everything measurable.

4. Performance

How to turn performance attributes into numbers.

3. Functions

This is what the system must do.

2. Requirement Specification

Outline of targets and constraints.

1 Planguage and process control

Intro to Planguage.

This book was written at a time when you actually had a mantained specification document alongside a system. I have only ever seen this in use once on a large project near the start of my career.

I have used some of these techniques to help choose between design alternatives. The whole process is too big to use for “small” tasks.

Lean processing was initially developed by Toyota. The innovation was to work in terms of flow rather than focussing on speed of production. This has been covered in many books:

• The Goal
• The Machine That Changed The World
• The Phoenix Project and it’s equal The Unicorn Project

The one that I am reading now is Freedom From Command and Control

This is an attempt to translate the Toyota process for service organisations, and in particular customer service.

The overall idea is to find and eliminate waste. Those best placed to detect the waste are those doing the work.
A starting point would be categorising calls into value vs failure management. Failure management results in finding things that should not happen. If these can be prevented then the volume of wasted repeat calls will decrease.

This is the basic Plan Do Study Act loop that is used at multiple levels in an agile project.

At the lowest level it is the Red-Green-Refactor cycle of TDD

At the task level it’s the do we know enough to know what to do, report what is finished and update the next steps.

At the initiative level it’s the breaking down items into discrete tasks and ensuring that each incrementally adds value.

At the team level it’s the retro and the resulting actions to drive improvements.

ets is the bare bones no persistence storage mechanism that has lived inside Erlang for decades.
It’s not pretty but does its job well.

Today I found etso a bare-bones Ecto wrapper for ets.
This does allow possibilities for rapid prototyping of systems.
You can see if the database structure makes sense without actually having to create the database.

Possibilities here get interesting. For example you could point a generator at openapi and have a system that implements the spec without ever touching a disk.

vimtutor -c 2

This was news to me. I had done most of the the first chapter many times.

I have been working in a company that has a large monolith. The developers have been split into domains and largely been focussed on their own area.

Over time each of the domains has atrophied their understanding of the other domains.

We recentlty had some larger cross domain projects started. These also cross into some of the systems that surround the monolith.

The pure DDD ideal of having a service belonging only to one team is now causing new bottlenecks. If a service needs to be used by all the surrounding systems this will happen.

The easiest solution would be to start accepting PRs from outside of the supporting team. The downside is that the bottleneck now becomes reviewing the changes.

We really need to have a big picture view of the system somewhere. Currently we have many competing (and contradictory) views.

Designers would benefit from this. We recently we given a piece of UI work that requires a new API from the constrained team.

We would have benefited from a user needs mapping session to make it clear which team owns the various capabilities.