Equational

Consistent design of multiple views of distributed state The notion of "state" is key to software development. For example, we talk about stateful and stateless designs. Still, there are multiple notions of state. For example, there is the stored state, the communicated state, the received state, the processed state. Therefor when we make a statement like "stateful", we are always just referring to one "notion" of state and not the others. This "abuse of stateful view" was historically not an major issue. Yet with the rise of processing speeds and truly distributed systems, these multiple views of states started more and more to exist "simultaneously" and this caused problems. For example, we might model a trading system as four different states: the state of trading action messages received by the exchange, the current state of the exchange, the state of confirmations received from the exchange, and the current state of our trading s...

Let it be known that when I significantly change jobs I buy a new laptop. Which is why I find myself typing this on the Lenovo x220 I purchased for 120CHF at the local used hardware shop here in Oerlikon. Once I have finished to set it up (it already has new SSD, RAM and battery pack for an extra 200CHF), my 13" MacBook will be mostly my work computer (for my technical advisor job). Here is a picture of it. If you care why I chose an x220 and the switch back to linux, then do read on. The thinking goes as follows: Leaving Apple: In 2015 I chose MacBooks as standard laptop for engineers at Elevence, really because when you get acquired, you need to be already halfway enterprise. Yet the choice became a pain because of the extra effort needed to get development tools running on Mac OS. Then in 2016, Apple stopped being developer friendly by killing touch typing with the Touch Bar, and worse by removing the Escape key. (And yes, of course you can reassign it, but that is n...

In summer 1996, I met Mattias Jansson and Lukas Lüthy (left and Luki middle above, I am at the right), as well as Adrian Lucas (left below) and in what seemed to be less than 15m, they were inviting me to join them set up a software company to develop a non-proprietary derivative market making system. Another key partner in this story is Stig Hubertsson (not shown). Therefore, we found ourselves co-founding QT Software, which later was renamed Actant . I bring up this past in this blog to cheer excellent individuals and a great team, and give you insights into how QT and Actant led me to co-found Elevence and develop a unique smart contract language (then acquired by Digital Asset). First the cheering: Still now Actant software is known to be the fastest non-proprietary derivative trading software. And while I don't have the numbers, I could well believe that they compete well with proprietary derivative trading software on classical hardware (meaning CPUs and not FPGAs)...

Modern architecture, for example for large cloud systems, have much in common with agile processes. You may know from past posts that I love agile processes. One reason is that agile processes have mathematical roots. The other is that when you know how to yield them, they deliver. I could talk for two hours on the subject! Here, for your comfort, the focus is just on the basic tie between an agile process and the architecture of modern data management. Here is the video (9m): Pictures from the video Hereunder, the main pictures of the video, in case you want to refer to them in your comments: 1) Concrete vs Abstract (horizontally) and Static vs Dynamic (vertically): (Note how I say concrete, but write "contract" in the video. That is a mistake, and what happens when you invent smart contracts and focus much on them!). 2) Agile process "functional schema" and data management "functional schema" side by side: 3) Waterfall process (...

# Skunk Works Rule Agile Interpretation 1 The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. Control is delegated to teams. Direction is owned by business/product team leads who report at the business stream level. 2 Strong but small project offices must be provided both by the military and industry. Leaders are strong and few. 3 The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems). Keep teams small. 4 A very simple drawing and drawing release system with great flexibility for making changes must be provided. A very simple process to integrate, validate and release the full deliverable must be provided. 5 There must be a minimum number of reports required, but important work must be recorded thoroughly. Process...

My favorite leadership approach is servant leadership! While leadership is needed for different reasons and is expressed in different ways, it is clear that certain styles of leadership are better suited for specific situations, characters of teams, groups and organisations.  Therefore: this blog entry about servant leadership... because it works for me! Note that this blog entry talks of teams... Teams which could be organizations, be hierarchical, etc... Servant leadership is not about structure but about method. Let's start by expressing a complementary view: what is not servant leadership. At the extreme we could mention dictatorship, but that would not help us much, and is in fact not complementary. Instead, it is better to bring up followership in which team members follow their leader. Let's now start with three defining aspects of followership: Leader with followership: Team leader communicates expectations, team members follow with goal to meet expectations ...