All things start with a question, and ours is:

"How do we create and ship software that thrives on the unknown and change?"

This is the essential challenge of antifragility in software.

Antifragile software thrives on change and embraces uncertainty. It's unique in that it is the underpinning and valuable property shared amongst a number of movements in the architecture and design of software, all of which aim to be a the 'elephant in the standup', i.e. all the software you've written before that makes it hard to build the software the way you need it today.

Antifragility underpins, amongst other things:

• Reactive Applications
• Micro Services
• Simplicity in Software

Valuing antifragility enough to work it into your design means your software, as well as you, can embrace change. Agile processes and ways of working have gone a long way towards helping humans and organisations embrace change (or not); antifragile software design and architecture helps your software keep up.

Without antifragility you end up fighting your code, expending huge amounts of effort just keeping the codebase moving forward at all; antifragile software is designed for the unexpected, in terms of change and runtime operation.

The first step to getting these gains is to understand and value antifragility.

For more information on Antifragility generally, the canonical book by Nassim Nicholas Taleb is the place to start.

For more on Antifragility in Software, that's what my book is all about and I expect to have a complete draft ready this week. If you can spare 3 days in London to learn about how to develop and evolve software faster than the competition, then my course at Skills Matter would be time well spent.

For help adopting antifragility in your own software, contact my team at Simplicity Itself.

The first and most obvious reason is that it takes effort. Much like simplicity, antifragility requires recognition and to be valued in order for it to be applied. Otherwise any antifragility is serendipitous at best.

Antifragile falls at the other end of the spectrum from fragile, with 'robust' the mid-point of the triad. Fragile software is evident in every decision to abandon a legacy codebase as it's fragility prevents it adapting to new needs. Robust software is often high quality for yesterday's problems and will withstand some change, but will often end up resisting your change when you really need it. All the best techniques of the craftsman often lead to this high quality but resistant to change software.

Antifragile software has been designed, architected and is delivered in such a way as to thrive on change. Change here, even the unexpected, is seen as an advantage.

After looking carefully over my recent and past software products, fragile design hurt me, robust design meant someone had to be upset, but antifragile design, architecture and delivery process delivered satisfaction to all quarters.

The fact is that people do occasionally deliver antifragile software. You only have to look to companies that are innovating at pace with their software products, and often with few people, to see antifragility in action.

The first step to getting these gains is to understand and value antifragility.

For more information on Antifragility generally, the canonical book by Nassim Nicholas Taleb is the place to start.

For more on Antifragility in Software, that's what my book is all about and I expect to have a complete draft ready this week. If you can spare 3 days in London to learn about how to develop and evolve software faster than the competition, then my course at Skills Matter would be time well spent.

For help adopting antifragility in your own software, contact my team at Simplicity Itself.

Antifragile software pays no heed to your choice of language, framework or even platform. It is simply measured in how easy it is for you to change your software, and as such there are several contributing factors to the antifragility of your software, a sample would be:

• Modularity
• De-coupling
• Confidence
• Human comprehension

Techniques such as BDD can contribute hugely to these goals. No one technique though can completely satisfy all.

Antifragility is a quality that we all recognise but rarely name. Naming antifragility and understanding it means we can aim for it, rather than accidentally achieve it.


For more information on Antifragility generally, the canonical book by Nassim Nicholas Taleb is the place to start.

For more on Antifragility in Software, that's what my book is all about and I expect to have a complete draft ready this week. If you can spare 3 days in London to learn about how to develop and evolve software faster than the competition, then my course at Skills Matter would be time well spent.

For help adopting antifragility in your own software, contact my team at Simplicity Itself.

On Friday I asked the lovely people on Twitter if anyone had any questions about antifragile software (twitter tag #antifragilesoftware) to DM me and I'd happily answer those questions. Thanks to everyone for the massive amount of feedback so far! I'll be getting to all those questions here and in my book and course in due time, but first...

Bar none, the most common question was "what's the benefit?". The answer is "there are lots", but this post will introduce the main one.

Antifragility takes effort to implement and so there had better be a benefit for that cost, right? Absolutely. The first big payback for designing your software with antifragility in mind (notice that this is NOT 'robust' software, nor 'fragile' software; this is software that thrives on change) is in the fact that antifragility helps you embrace change. The secret is in the subtitle of the key book on Antifragility, "Things that gain from disorder". 

Projects, products and needs are unpredictable, that was why we originally got into agile software development in the first place. Antifragility is a key property of your software if it too is going to be able to keep pace with emerging needs placed upon it, and not end up being the 'elephant in the standup' (more on the elephant in a forthcoming post).

So if you want to build software that embraces change and gives you an edge when aiming to be faster to market than your competitors (or just to impress the boss with your speed), antifragility is going to be something you want to design in.

For more information on Antifragility generally, the canonical book by Nassim Nicholas Taleb is the place to start.

For more on Antifragility in Software, that's what my book is all about and I expect to have a complete draft ready this week. If you can spare 3 days in London to learn about how to develop and evolve software faster than the competition, then my course at Skills Matter would be time well spent.

For help adopting antifragility in your own software, contact my team at Simplicity Itself.

More posts coming soon based on the wonderful questions I received from the twitterati!

I'm constantly on the hunt for ways to reduce what look like extremely complex activities and reduce them down to their core, and very few activities come much more complex than the development of software. It is in the essence of such activities that a person's motivations, rationale and uptime view of value can be understood, and so the effort of analysis seems worth it.

However I'm fairly sure there's a simple set of urges behind the majority of software developers out there, and they are:

• We like being creative
• We like building stuff
• We used to play with Lego (other brands of build-it-yourself-toy are also available).

As software developers it's often hard to see what we're actually building. We work in an ephemeral substance that often only we understand, which tends to contribute to our relative lack of contribution at the average dinner party.

Under the surface though, we are all builders, and I suspect that we have similar mental models for what we're building that make it easy for us to adopt certain techniques, but not others.

Object Orientation (OO) is about creating building blocks, objects, that can be fitted together to implement some useful functionality. Despite many attacks over recent years, OO is still the dominant force for thinking and building software in the IT industry, and one factor I believe is its strong analogy to a friendly memory from our childhoods... namely, Lego.

So here's the rub. I think that the majority of software developers are at heart quite surprised, but loving the fact, that they are effectively being paid to work with Lego. 

Admittedly the Lego set has become a LOT more complex, with pieces of all sorts of custom shapes and only a few guidelines for how to make good pieces that can be comprehended by other people, but still ... we're playing with Lego and getting paid for the pleasure.

And so we come to Functional Programming. Functional Programming has been around for years, come and gone with the tides, and is currently back with the force of simplifying software in many ways. This is a good thing but it does face challenges with adoption, and one challenge will become evident if you buy my argument that software development is approached like building with Lego, namely:

• Functions are not easily analogous Lego Blocks

This is not to say that functional programming is not valuable and has some real potential in simplifying the software we need to write. It's just that the analog of having a thing, an object, hits out respective Lego-building buttons; having an activity, a function, doesn't so easily cut it in our mental model.

Aside from this, one slightly positive outcome of the friction between functional programming and Lego-building-mental-models, is that there is a certain smugness to having got to grips with functional programming. A smugness that transcends the language chosen. It is the smugness that comes from realising on some deep level that we've broken out of our original habits, and found a whole new set of Lego pieces.

We've jumped from Duplo to Lego Technics.

At first glance it can seem like I'm entirely trivialising software development to the simple activity of playing with Lego, but that's not my intention. Software development is an intense, intellectually challenging activity that involved research and development. 

I suspect that the joy of building software comes from a similar joy that occurs when building something with Lego, with the same dangerous urges to build something overcomplicated to express our smartness. 

My take is that the Lego analogy might have some deep ramifications for understanding why our software tends to surprise us in odd ways, which is one purpose of an analogy in the first place.

So, how's your Lego building going today?

Money can be its own end, but not to everyone. While wandering across a windswept but briefly sunny London Bridge this morning, one of the mileiu fleeing London Bridge station and trying not to accidentally fall into the familiar rush of London-speed-walking, I realised that money means almost absolutely nothing on its own to me.

Money to some people has the attractive, hoarding relationship that contributes so neatly to their need for security, but this is not the case for everyone and not the case for me. For others, money is more often than not simply a stepping stone to a new guitar, a motorbike, or paying off a debt (not that those examples are specific of course..). To these people, on its own money in itself is boring.

This attitude perhaps would not be too dangerous. The problem is that it is often coupled with an attitude to consumerism that can at certain times be difficult, and at other times severely damaging.

When money itself holds so little intrinsic value, several self-selling strategies can rule within our minds:

1. "I deserve it" thinking. I work hard, therefore this item/thing is something I am entitled too, dammit.
2. "What if I don't? Will I ever find the 'perfect' thing again" thinking.

Given these twin forces, we often find ourselves buying something that not only ends up adding almost nothing to our overall happiness, but in fact contributes more than its fair share of impact on increasing our guilt and disappointing sense of shallowness. 

At our most masochistically brutal moments, we may even reduce ourselves to wrecks who believe we are worthless for having spent 'so much money' on 'something I can't even enjoy now'. We appear to be our own best salesman and torturer in tight chronological sequence.

One technique that works to a certain degree is the Epicurean-style thought experiment that looks to the happiness that might result in the future after a given purchase. The experiment goes something like the following:

1. Consider something you're intending to buy.
2. Stop and think about how you will feel in the future if you have that thing. Imagine the consequences, the benefits and disadvantages on your overall condition if you have that item.
3. On balance, decide to make the purchase if the outcome is to the good in terms of your happiness.

Common sense, no? It turns out most often it's unfortunately not. A combination of good salesmanship, externally and internally to the mind of the buyer, often circumvents even this simple thought experiment.

So what else could you do?

The previous thought experiment tends to appeal to rational thought, and often that is very much lacking in the heat of the moment of an impulse buy, especially an expensive one where your inner salesman is working overtime to get your to hand over your cash.

Two questions I've found that better appeal to my own sensibilities are around introducing feelings into the mix. The two questions that have had most impact in curtailing my own wanton purchasing urges are:

• If everything I had now was all I ever had, would it be enough?
• If everything I had was all I ever had, what would I miss?

These questions are quicker to think about. I tend to have a real emotional response to the emerging responses to the questions that quickly dampens my desire for the thing-under-purchase.

These questions work for me, for others I wouldn't be able to guess. What works for you?

Not too long ago Daniel Gilbert wrote the amazing book "Stumbling on Happiness". The main crux as I read it is that our brain affects how we think we'll feel in the future, including what might make us happy. Our brains have the tendency to ignore gaps in our interpretations of the future, and this can mean we can easily be influenced by current environment and context into making decisions that are influenced heavily into the positive or negative outcomes.

My take is that we can only do the best with what we have. Nothing beats 'taking time' when making a decision, and the amount of time you're willing to take will likely be a snap-judgement on the overall risk you're taking (not necessarily a bad thing either, if you're to believe Malcolm Gladwell's findings documented in his excellent book "Blink"). 


Gilbert's proposed answer to this conundrum is to find other people who have made this decision and ask them how happy it made them. That sounds a little ideal to me, and is far from easy when you're staring at that brand new Gibson Les Paul with your internal salesman in full swing and an eager external salesman giving the distinct impression that your next 5 minutes will decide if his family eats this week...

For some time now, in fact since my brief time as a student at Eastbourne 6th Form College (now Park College) which was far too long ago, I have been very interested in Psychology. 

It's a slightly-hidden secret that the subject came a very close second when I originally considered what I might pursue as a career, and in more recent times with a different perspective on life I've begun to pursue it again. 

Call it time of life, call it a mid-life crisis; the workings of the brain are tremendously exciting to me, not least because we all own such a highly complex piece of machinery.

The fact is that most of us drive our brains with little understanding of how they work. After some initial middlings in early childhood, our brains for the most of us 'just work'. Until they don't.

When they don't, it is unfortunately still a real stigma that there is only limited help, empathy and acceptance from even our modern society. Education and mental health professionals of all walks of life are working hard to redress the balance, but it's likely going to take a long time before "it's all in your mind" is treated with the same rolling of the eyes and, sometimes, disgust as "it's just because she's a woman" does now.

All of this curiosity with Psychology was mostly of simply academic interest to me until two things occurred in my life.

First, I came very close to a serious mental breakdown. 20 years of high anxiety levels pushing me to work both 'harder and smarter', the modern ideals, had taken their toll and the sudden lack of control evident in my divorce pushed me over the brink. Suddenly, Psychology and Philosophy became personal.

Secondly I read a book. This on its own is not too surprising, many who know me will sigh at the thought of the literary weight that needs to be shifted even when I consider moving house. But this time I read one of those wonderful, perspective-changing books. It was "Quiet" by Susan Cain.

This beautiful book tells the story of being introverted in a society that has bought into the Extrovert Ideal. With both personal and society-wide implications, Susan conveys with frustration, sadness that:

1. Introversion is a choice and that you just need to "get out there"
2. Introversion is a handicap to be avoided

Susan's book ends with a search for change in recognition of the real value of introverts, and this got me thinking about my own experiences as a software developer.

I started to look at contemporary processes and practices in software development differently. I began to ask different questions...

The interesting effect that "Quiet" has on me was to open my eyes to just how little of modern life embraces the needs of introverts, instead preferring to emphasise overcoming that 'condition'. 

I began to look at my own software development practices, even advice I proffered, under a different lens and found to my dismay that I too was potentially advocating processes, practices, tools and techniques that could run counter to an introvert's needs, simply because a vocal extrovert 'majority' (rarely a majority in fact, just the loudest voices) had made the original arguments.

The dismay turned to incredible embarrassment when I realised that I too was an introvert and had completely bought into the idea that this was something to be overcome. So every time I felt deeply uncomfortable with a practice in software development, I would find myself only focussing on the confirmation-biased induced outcomes rather than the real value and impact on my own mental health.

I had, quite by accident, become something of a snake-oil salesman around the processes and practices of software development that all seemed quite reasonable, until viewed as to their impact on an individual's mental health.

The Metro free paper in London recently drew attention to the "Mental Health Debt" that we as a country are accruing in regards to our youth due in large part to the environment and social pressures that they experience. I'm no longer a youth myself (a margin of some decades now I'm afraid) but I don't feel that that debt is limited to the young.

Of course that debt is also manifest and increasing in many different domains and industries, but our industry makes its money off of an intellectual pursuit and so I'd like to look at how that intellectual pursuit might be being hamstrung by its own good intentions.

There are also rich pickings for analysis in software development when cast through the filter of their effects on mental health. Just for starters it is worth looking at:

• Pair Programming, especially mandated Pair Programming
• Team working
• Brainstorming and its constraints around creativity
• Task-only focussing
• Keyboard Ballet... (or stop thinking, productivity only happens when keyboards are clacking)

The list does quite literally go on. 

We have an interesting area of analysis, an area where someone's brain can be all the different between a world-beating product and a failure, and a collections of half-proven (at best), extrovert-centric processes and practices. It'd be akin to industry-abuse if we didn't consider these things more closely wouldn't it? 

So what can be done? Firstly, I believe it's time to recognise the problem. While I entirely concede that mental health is affected by many different issues with society and individual circumstance, they say you should write and consider what you know a bit about and since I know a bit about software development, and know a lot of unhappy software developers, this is where I'm going to begin my stand.

I'd like to start an interest group, let's call it the "Psychology in Software Development" group for now, initially here in London but possibly with a more far-reaching mailing list at first if there's interest, that discusses and calls for action around improving the mental health of software developers. I would like that group to take a careful look at the processes, practices, working environments and pressures of our day-to-day work and begin to illuminate where those factors work against the mental health of the people involved.

It would also be really great if existing groups that touch upon the human interests of software development also picked up this thread. I particularly like the look of the PPIG, not least for the iconography involved. PPIG have been working in this space for some 25 years, and an organisation with that wealth of experience could make real headway in respected empirical research around the effects of software processes and practices on mental health. 

The PPIG is not alone. Others who might take an interest and bring much to this space could include The School of Life, and it's accompanying truly wonderful periodical The Philosopher's Mail could likely also provide important insights into these topics.

In the coming days and weeks I'll be updating this space with where my thoughts and actions are going in this potentially fascinating space. If you'd like to get involved or are just interested in hearing more about how things are going, feel free to get in contact with using the following form:

Welcome to my attempts. Attempts and Trials are two generally accepted translation of the original French word of Essais, that through the years of formal college and university schooling have been almost literally corrupted into the ennui inducing literary forms of essays.

My essays attempt (pun very much intended) to stay true to the original meaning of the word. Sometimes shocking, sometimes quite likely literally sleep-inducing, my essays will attempt in my limited fashion to explore my perspectives on life in a slightly more longer form that Facebook and Twitter might allow.

My intention is to quite literally write about anything of worth as and when it occurs to me. Worth here is defined by something I've found interesting enough to think about and nothing more. This means that if for whatever reason I choose to talk about the wild hairs that have decided to advance their growth from my eyebrows and how this could ever conceivably be an evolutionary advantage of any sort, rather than perhaps expound on world politics for example, then for this I make not apologies whatsoever.

My biggest hope for these attempts is that I and you my dear reader may stumble upon some shared understandings on some of the more menial aspects of modern life, and on the way come up with ideas and maybe even practical tools that may make us feel less alone in these modern conditions. There are of course no guarantees of this at all, but with the best of intentions if just one essay touches and informs just one other human being on any aspect of their lives, I'll consider my writing time well spent.

As is customary these days, all opinions expressed here are my own and do not reflect the opinions of my employers, partners, associates or even friends. They're mine, all mine I tell you!

I also don't have an editor so I guess I also have to take personal responsibility for the abysmal use of language and punctuation. So sorry for that too.

It's been a long time since I wrote anything publicly (ok, a VERY long time) and although I used to find the experience fun, rewarding and amazingly cathartic, I just dropped easily out of the habit in a cloud of disillusionment, fear and, for want of a better word, 'meh'.

So now I'm back. I'm not sure what I'm going to write but what I can promise is that it'll be honest, at times funny, at other times perhaps shocking but regardless, I'm going to have some fun with this this time.