Equational

What can we learn from chess to better our agile management? Here I use analogies from the game  to highlight a few important concept that all agile team members should be aware of. For example, the game of chess highlights the difference between the strength of individuals versus the strength of teams, as well as the difference between experience versus talent.  I watched a few of the 2013 world chess championship games between Carlsen and Anand. (I am not a chess player, I am just happy to be a good spectator). It was a great fight! Looking back you might say that Anand just made too many mistakes, yet during the match I think that many of us though that Anand had good chance to do much better. While watching those games, I could not help seeing some of the universal principals that can also be found in management. To explain the analogy, I first present the chess concepts, and then map these into a management world. When you learn chess, you learn that pawns are the w...

The other day I was talking project management with a development manager, and I was not careful to wear my "member of the project manager club" social persona. Instead, I did what I usually do which is to focus more on competence and collaborations, and less on  titles. I little too late, I realized that I had just offended this person. The truth is, many of us include our job title in our social identity. Therefore when I did not show respect for the "social stance of project leaders",  this person felt personally aggressed, and to protect himself, needed to think that I was not being coherent. My daughter wanted to write a story recently. I gave here the following advice: You always have two choices: You can start with events and then describe the resulting emotions, or start with emotions and then describe the resulting events. Just apply this rule over and over.  An example:  "The man hit the dog, and everyone was sad" versus  "It was a s...

This weekend I watched Computer Chess and The Internship on Apple TV. Sadly, I feel that both film fail my test for being great. Computer chess is really pretty fun. It is not "funny" but brings enough retro geeky elements into the script to touch a lot of "über nerd" soft spots. If you are like me and have lived the late seventies and early eighties micro-computer revolution, then you definitely get value of the first three quarters of the film. The let down is the last quarter. I will not spoil your fun by giving you the plot, but I can say that the film tries to meet up with a broader audience by bringing in deep issues of faith within a "fantastic" settings. I just didn't feel this worked. The internship suffers a similar "try to broaden appeal" problem. The issue here is sex. Maybe it is the reediting for the Apple TV version, or I am just old fashion, but this film had way to much "open" sexual dialog (and scenes), and ...

Misfits of science Talented people are outstanding at what they do best... and often dysfunctional in one way or another. This post is about how to manage talented people. And especially about managing them within organizations that need a lot of collaboration (e.g. software development). I'll start with a quote from a TV show from the eighties: "Everybody that is worth the trouble is a little weird" (To be found in  episode three of the Misfits of Science )   I have worked with many talented people that were "pretty normal", yet I would need to argue that the majority of the "good people", those that are worth the trouble to "keep", from a management perspective, are also "focused in their own way". And even the talented people that did not show outward signs of "idiosyncratic" behavior, had their special side, which within work organization often showed up as social issues in abrupt or surprisin...

Most of us have probably worked all night and all weekend sessions in order to finish a project "on time". And we all know that is the sign of "bad management", and can also be the sign of an impossible task. Therefore, looking back at the US government working hard a few days before the deadline to get the debt ceiling raised, can be seen as a sign that the US government is badly managed, but can also be seen as a sign that it had an something impossible to do. You might say, a government and politicians is not the same as a software development organization. Governments are fragmented, many politicians only have a job because of these differences of opinions, politicians are continuously trying to shift blame, etc. While the goal of all members of a software development team is to finish a project on time and be successful.  Or is it?...Hmmm...  In fact, that is not always clear! ...

Here my attempt to match up design patterns with functional programming constructions: Chain of responsibility Fold request across the chain of handlers, at each step returning either (using Either type) request to continue fold (possibly with transformed request), or returning handled request indicating that fold is finished. Command Request is held in data (e.g. as discriminant union) Interpreter Language is available as typed data structure (e.g. discriminant union) and is interpretable with functions calls. Alternative:Language is defined in monadic form (e.g. as function calls)  and is interpreted as part of the monad's interpretation. Iterator Exposed traversal functions hide data structure of containers. Functions typically work on zipper focus adapted to the containers structure.   Mediator Exposed functions stay at top/root of exposed data structures. Memento Use immutability and exposure of intermediate states to allow recovery, restart or alternate...

My favorite skateboarders these days are Rodney Mullen, Ben Raybourn, Chris Haslam, and Chris Cole. There is an interview of Rodney Mullen where he says he is looking for a special "silhouette" in skaters. In fact, he is saying the he is looking for uniquely talented skaters that have internalized their skating into their cognitive growth process. To give you a mental image of what I am saying: We all need things we can lean on to grow. What I mean by "leaning on something", is that we use it to support us, we use it as dependable reference. When we are young we lean on our parents. Later, most of us lean on our social/economic "fabric". Yet others lean on their own selves. If you are unlucky, this self "leaning" may make you a unpleasant narcissistic person, yet if you are more lucky you do not lean on a "synthetic" self created social reference, like a narcissist person, but on a self created non-social reference. And for the people...

Financial exchanges can be seen as big computer clusters that are accessed through specialized APIs.  There are usually a few different ways to access an exchange. The connectivity can be direct or indirect, and there are usually different APIs for the different services.  Direct connectivity is the fastest way to interact with the exchange and pretty much implies that you are a member of the exchange or that you are working closely with an exchange member. If you cannot afford or do not want to bother with direct connectivity then you access the exchange indirectly: your system will connect to a broker’s system that is connected to the exchange.  Such a broker access may bundle up the different services into one API (e.g. using the FIX protocol). Direct connectivity usually has different APIs for different services.  Typically there might be a trading API, a price feed API and a clearing API. Orders and quotes are entered and updated on the trading API.  This A...

Electricity, magnetism and time are tightly intertwined. You can try to work separately with them but that will not give you the whole picture. While if you consider the dynamic relation between all three, you can do magical things. For example, you can “bounces” electrical energy back and forth into magnetic energy resulting in alternative current, which magically almost avoiding the need to actually carry “real current” (which is expensive). Or you can “juggle” these energies while moving forward, and thereby creating photons and light. In project management, tasks, resources and time are also tightly intertwined. You can try to work with them separately but again at risk of being inefficient.  It is a bit of a stretch to compare project management with electromagnetism, yet it is intuitively pleasing. In electromagnetism, work is created by “applying” electrical currents and magnetic fields on each other. In project management, work is creating by “applying” tasks and resource...

This blog post is about two basic requirements when asking developers to write a very fast algorithmic trading systems. Designing fast system seems initially an easy task. You hire developers that are in touch with the physical nature of computers and networks. And you ask them to write fast code. Nevertheless, there are difficulties. The first is that allocating and freeing dynamic memory slows you down, so ideally you want to do without dynamic memory. Yet developers usually have a hard time with this requirement. One reason that developers are insecure in doing this is that they have been brought up with languages that only work with dynamic memory. The other reason is exactly the language issue: modern languages do not make it easy to program without dynamic memory allocation. Therefore it is best to present this requirement differently, in a form that is much easier to swallow, which could be as follows: Make sure to preallocate your dynamic memory before activating your algos...

Have you noticed that people can make sense of what does not make sense when they do not understand it? That is the "soft" and "analogic" property of our brain: we can make sense out of nonsense,  and this is ok, when we do not know it is nonsense! A waterfall process will take nonsense, and then often spend the money while delivering nonsense. Agile process will take nonsense, and fail iterations, and... just go on, spend your money, and  delivery nonsense, or...,  recognise the stalling as a failure to deliver the requirements (e.g. sprint stories), and then force the requirements to be rewritten for the next development iteration. The next iteration may fail, but again the requirements will need to be rewritten. Yet if you are truthfully applying an agile process, each failed delivery will again attempt to reformulate the requirements to be achievable and in the end what was not understood and is blocking you becomes understood and you either stop the project, ...

Maintaining consistency within parallel, distributed, high-performance, and stream oriented programming is all about accepting one thing: when it comes to consistency, that is dealing with failures, don't promise too much too soon! And that is the whole notion of eventual consistency: you sometimes need to wait for things to get resolved. "How much you wait" depends typically on how much money you have invested in infrastructure, yet it also depends on how fine your system captures failures. Let's start with the eventual consistency.  In traditional transactional models, consistency, the knowledge that your system is "doing well", is assured by approaching each operation "transactionaly": if an operation fails, make sure nothing is messed up and that consistency is maintained.  Yet in the "new" world of massive parallelism, need for high-performance, and the like of streaming models, it is often simply impossible to maintain consistency...