When I speak to people about how it is possible to continuously deliver customer value with near zero issues, I usually get laughed at.
After I tell them that there is nothing to laugh at, people start challenging me on how I integrate with other systems, how I manage defects, how I deal with changing requirements, how I manage regression issues, and how I cope with context switching and other similar issues.
Luckily enough I have empirical data and my answers are based on experience and not some book or model I read about somewhere, so after a while I manage to get people moving from laughing at me to at least starting to be curious.
It has to be said, people become curious but deep inside they still don’t believe me and still think I am a big fool.
How could I blame them? I would have done the same a few years back. I know that people need to have to prove it for themselves to be able to believe it, I have no problem with that.
While I manage to explain my way of dealing with defects, changing requirements, regression, and context switching, until now I haven’t been able to answer the biggest question of them all, the one that every conversation ends up with eventually: how do you deal with extremely complex systems that need to scale up?
I have been thinking about this for a while now and the more I think about it the more I become convinced that Complexity is the Excuse.
Complexity exists when we are not able to prioritise the value to deliver (we don’t know what we really want).
Complexity exist when we are not able to understand and describe the system we are building.
And finally, Complexity is a nice excuse for not doing our job properly as software engineers and having something to blame.
Reduce Complexity and stop taking excuses:
- You want to deliver customer value, OK. You don’t need to deliver everything on day 1. Sit down with your business partners and identify the highest value added feature and focus on that one. If asked for bells and whistles, say, “we will do it later and only if we really need to”, chances are when you are finished doing the first feature you will have learned that you need something different anyway.
- When deciding how to implement such feature, look for the simplest and cheapest solution, do NOT future proof. By future proofing you will be adding complexity and guess what? YAGNI. Measure the success of your feature and feel free to change direction, failure is learning.
- Once you have identified the value to be delivered, make sure you break down its own complexity. If a user story or unit of work or whatever you call it has more than one happy path, then it is too complex, break it down into 2 or more units of work.
- If you start working on something and you discover it is more complex than you had thought, then stop and break it down to less complex units, if you keep on going saying nothing, you will hide complexity and sooner or later you are bound to mess it up.
Scaling up is the wrong answer to the false complexity question.
Chances are you don’t need to scale up at all: Read 1 and 2 again and again, you will find out that you don’t need as many resources as you thought you would. Scaling up, most of the times, is the easiest, most expensive and laziest approach to fight complexity.
For doing 1. and 2. in a structured manner I strongly recommend an approach called Impact Mapping devised by Gojko Adzic, it works.
For doing 3. click here
For doing 4. use your head.
TL;DR: stop blaming complexity when you don’t understand what you are building.
| Reference: | Complexity is the Excuse from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
Thank you. I have long believed that most things are simple, and that people create complications around them. It’s ultimately 1’s and 0’s.