Github has finally updated the mermaid component so that the mermaid beta now works!
Living with an older mac
My macbook is now outside the supported range of homebrew.
I am now moving to use macports.
Mermaid Wardley Map Example Tea Shop
I am starting to experiment with the Mermaid Wardley Map
<html> <body> <pre class="mermaid"> wardley-beta title Tea Shop size [1100, 800] anchor Business [0.95, 0.63] anchor Public [0.95, 0.78] component Cup of Tea [0.79, 0.61] label [19, -4] component Cup [0.73, 0.78] component Tea [0.63, 0.81] component Hot Water [0.52, 0.80] component Water [0.38, 0.82] component Kettle [0.43, 0.35] label [-57, 4] component Power [0.1, 0.7] label [-27, 20] Business -> Cup of Tea Public -> Cup of Tea Cup of Tea -> Cup Cup of Tea -> Tea Cup of Tea -> Hot Water Hot Water -> Water Hot Water -> Kettle Kettle -> Power evolve Kettle 0.62 evolve Power 0.89 note "Standardising power allows Kettles to evolve faster" [0.30, 0.49] note "Hot water is obvious and well known" [0.48, 0.80] note "A generic note appeared" [0.23, 0.33] </pre> <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); </script> </body></html>
Not a bad start.
Minimal Wardley Map in Mermaid js
I have been following the wardley map addition to mermaid js
<html> <body> <pre class="mermaid"> wardley-beta title Software Platform Strategy size [1100, 800] evolution Genesis@0.25 -> Custom@0.5 -> Product@0.75 -> Commodity@1.0 anchor Customer [0.90, 0.95] component Something [0.5, 0.5] Customer -> Something </pre> <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); </script> </body></html>
This is a terrible example of a wardley map, but does give a starting point for exploring.
I now need to wait for the github and notion components to be updated!
Currently github is on 11.13.0
Notion is on 11.10.0
The miro plugin is back on 10.x so getting rather old!
It was the year that they immanentized the Eschaton
This is a line from the start of the Illuminatus Trilogy. This was a series of satirical novels written in the 1970s. I read them in the late 80s/early 90s.
The phrase literally means actively bringing about the end of the world.
This is the first time that I have known of a war when key agents on both sides are trying to bring about the end of the world.
Pete Hegseth (Secretary of War) openly pushes end-times prophecy.
Shia theology also has strong end of days themes.
This combo makes the mutually assured destruction thinking from the cold war break down.
Wardley Maps are now available in Mermaid
Wardley Maps are getting closer to being included in MermaidJS
This PR is getting close to being merged into MermaidJs.
This will be a great boost to the Wardley Map tools so that we will have “native” Wardley Map support in github and notion (at least).
Congrats to tractorjuice for doing the hard work.
AI and Managing Outsourcing
There are claims that AI has solved writing code. This implies that we have recreated the outsourcing model.
The problem is that writing code is not the goal. We really want to solve problems and find using a computer to do the job is the most efficient way to do this. A large part of the value I bring is to understand how a system works. That way we can make changes that improve the existing system.
Some years ago a project was run at a company where I worked. The manager thought it was clever to hire a team of the cheapest developers he could find. The team was limited to 7 people since that was the power supply limit of the available room. The two permanent developers did their best to give instructions to this team. We had a suite of acceptance tests that was heading to being green as the critical launch day arrived. Two of the team had commit rights revoked due to repeatedly committing broken code.
Not being involved in the project I left the office at my usual end of day time. The next morning I arrived and found out about the chaos that had ensued.
2 of the 7 subsystems deployed to production were simply mocks. These were sufficient to get the test scripts to work.
The team QA had quit twice (the first time being talked down). The two in house devs had to implement minimal versions of the services. Mangement had introduced a no-one goes home til this works policy after I had left. The devs had been checked into a nearby hotel late that night!
In the end we had a shop that could not sell anything until halfway through the next day.
It took about a year to get the system into a sane state before we replaced it again.
Management had considered this a success. This was mostly due to us eliminating an Oracle DB that would have cost a fortune to renew.
This is what happens with a small team of developers. This is exactly what people are doing with AI. They are generating systems from incomplete specifications.
Why is my screenshare going slow?
I had fun this week with using google meet to share my desktop it became so slow that I could not communicate effectively. There seem to be two causes:
Google meet is less effective on Firefox than on Chrome. This could be by design. Moving from Firefox to Chrome for the sharing made a big improvement, but did not fix everything.
The second issue was found using top. I had a number of instances of rg that started to use 100% of the CPU. This coincident with VS Code starting searches that it did not finish.
In the end it came down to the small gear icon shown below. It needs to be in the “Use exclude settings and ignore file mode”
Flow and Work In Progress
Near the beginning of my career the lag between writing code and it being deployed in production was about 6 months. It could be 2 weeks before a tester deployed it to check it. Feedback was almost non-existant and you frequently had to investigate what you had written all that time ago (plus all the other changes the team had made to it).
We had what would be described now as long lived branches. One of my colleagues had to maintain fixes for bugs and feature parity across 7 active branches.
Today it is possible to have a small change be suggested in the morning, and implement it, then deploy it that afternoon. This is a 180:1 improvement in throughput!
Releasing every six months resulted in frantic planning and regression testing. This encouraged huge batches of work, with regression test cycles and lots of handovers.
Now we try and release as little in a batch as we can. If there is any risk it can be a single PR deploy. If bugs are found you can quickly isolate the cause and fix/revert.
There is now realistic feedback on changes.
We now try and strip every PR down to something that adds value to a system. It may take 3 of these before a customer sees a change, but the risk of merge conflicts has almost been eliminated.
The practical benefit is that you can experiment with small improvements and find out how to improve the system as a whole.
We also release far more features than in the 6 month cycles we used to have.
Developer Rants 