Equational

  My end of 2022 predictions for software development: Structure of code becomes more important than code Partial code becomes more valuable than finalized code Proprietary code gains in value Contextual programming gains in traction IDEs become ever more ML driven And therefore: Dynamic typing gains over static typing Duck-typing grows in value IDE security and spyware become an ever more important topic Functional programming is still the more powerful programming paradigm Proprietary IDE with in-house ML engines will grow in importance All original content copyright James Litsios, 2022. 

 My summer 2000 lunches were taken sitting under the twin towers in New York. I was there for the recently opened Actant's NY office , and would either have lunch at Battery Park or looking up at the towers. I have sometimes described my work as "if I were an architect, I would design skyscrapers", to then add "it is a pride thing, but also life is short, so let's push things forward". To eat my lunch below the towers, was in part to bask in the marvel of engineering tall buildings, but also to feel the ego that drives us to surpass ourself, and often others too.  These are some pictures of the towers I took: When the towers went down, I truly could not believe it. My old black and white TV had been switched on in the office (in Zug, Switzerland), my colleagues were huddled in front of it, I walked over, to hear someone say "one of the towers is down", to which I answered: "that is not possible, it must be hidden by the other". It was a s...

Not so long ago a good friend of mine mentioned his need for 'formal properties' in his code.   I asked him if he had already made the code purely monadic. He had. "Good", I said, "because the 'cheap route to formal properties' is first to ‘monadize' your code, and then 'reverse it' by bringing in 'co-execution'".  That last part needs some development.  Formal properties are not only about execution, actually mostly not about execution, but more about formal properties of state. So while you do need to show execution invariants, you often much more need to show that the ‘results’ happen within stateful invariants (e.g. of the ledger). The easiest way to do this is to  deconstruct / co-execute the state model backwards. This 'backwards' logic must 'match-up' with the 'forward execution' (monadic) model. My view has always been comonads are easiest for this, especially if your stateful model (e.g. a blockcha...

Dog Drives Car  Silly me shared the following picture with my sister-in-law yesterday, as she was stuck in a massive traffic jam with her dog (in photo) in her mini.  "How did you make the picture" was the question. "PowerPoint" was my reply. I used PowerPoint for that photo because it took me three minutes, and I had a slide deck open. Stop, you might say, this has nothing to do with programming, or software designs! It does if we want to design a software where a dog drives. Yet how would we approach that? Here I tell you how I have designed and communicated designs of 'big and bold' softwares quickly and with good properties. And will also sketch out how to approach exotic requirements, such as dogs driving cars. Arrows Away! Let me show you how I work. This how I use to draw design 28 years ago (from my PhD thesis): This is how I would have drawn that design 18 years ago (~2004): Here I use arrows to represent flows. Arrows are used to capture the Lagran...

Use your brains when developing abstract innovation. It is a game of 'balance': you think-up what is needed, you set goals that take advantage of your thinking, then you work towards your goals. If on the way something does not fit, review your goals or thinking. It is an iterative effort, you try, you repeat, until it works. Here are the three iterative steps in more details: State what you believe is true Express implementation goals that will leverage your beliefs Check consistency of goals with respect to your environment and to underlying beliefs Correct your beliefs if inconsistencies are found between goals and environment Develop towards your implementation goals Check consistency of development with respect to environment and underlying goals and beliefs Correct goals or beliefs if inconsistencies found between development and environment At first, one tends often to 'juggle' and develop just one idea at a time, when developing this way. Yet with experience it ...

July 1 2015,  I moved into a single office room at the Zurich Technopark  as the sole founding employee of Elevence Digital Finance (11ce). I assembled my sit-stand-desk. I used my personal laptop to write the specs for an 'authenticated contract logic database'. Also, I setup my beamer and flip chart stand! I mention this because I found the following note today dated July 1, 2015, where I 'sold' those objects to 11ce: We used this beamer internally, yet more importantly, we used it to pitches the contract modelling language we developed that year. 11ce was crazy successful and acquired by Digital Asset in 2016 . All original content copyright James Litsios, 2022.

A classical way to look at parallel / distributed systems is in terms of: Work-Efficiency Parallelism Locality  This is one of those inconsistent triads  (or trilemma ), where only two among three properties can be chosen. For example, a system can have both work-efficiency and parallelism, or parallelism and locality but cannot be fully work-efficient, parallel and local. This is not the only inconsistent triads to think about when designing scalable systems. Here are more: Velocity Resources Work Momentum Quality Traffic And of course the CAP theorem's: Consistency Availability Partition tolerance And the important: Fast Good Cheap All of these are ultimately important, yet some of these are more practically useful. Especially when you realise that you can weaken the inconsistent of these triads by introducing additional complementary properties.  To illustrate this with examples: Two people must work together vs an engineer and a sales person must work together Two tim...

Failing smart   My agile mantra is much: "Failures must bring you closer to your vision" It is a mantra I have often used. And very much how I approach agile innovation (e.g. see Search and Vision for Systematic Innovation ) However... It is only partially true, as failure may happen simply because you are disorganised, with no relations to your vision. Fixing organisation issues helps avoid drifting further away from your vision, it does not bring you closer to your vision! Still, unmanaged organisational issues will eventually consume you 'from within', therefore they too must be addressed. Can we focus on fixing organisation issues? Can we identify a subset of failures as 'organisational failures', and others as 'non-organisational failures on the way to our vision'? The simple answer is yes! Yet we must know what we are looking for. Six types of failures When I act as agile manager I try to distinguish between six types of failures. These are: F...