Speed, Agility, Resilience
Trusted Experts in Microservices, Cloud Native & Chaos Engineering
  • Home
  • EBooks
  • Contact Us
  • Consultancy
    • One-to-One Online Consultancy
    • Onsite Consultancy
  • Training
    • One-to-One Online Training
    • Building Reliable Systems
    • Building Antifragile Systems with Microservices Course
    • Fast Track to Cloud Native Java
    • Fast Track to Applying DDD for Effective Microservices
    • Fast Track to Running Production Microservices
    • Fast Track to Chaos Engineering
    • Autumn of Cloud Native
  • Speaking
    • Schedule
    • Slides and Videos
    • Brown Bag Events
  • Blog
  • FAQ
  • Client Feedback
  • Gallery
  • (Print) Books
  • Essais

Why Software is rarely the friend of Change...

2/10/2016

0 Comments

 
by Russ Miles & Sylvain Hellegouarch (Simplicity Itself), 10th February, 2016
I was just introduced to this wonderful talk by Richard Cook on systems resilience by my good friend, Sylvain Hellegouarch

Richard's main point seems to be that the fundamental battle any software delivery and operation team faces is made of three, often implicit, boundaries:
  • Responding to economic need to avoid failure: Adding or updating features, supporting different expectations...
  • Coping with workload: Teams need to feel confident and at ease they can deliver. If they feel overloaded, they either collapse or go to sleep mode
  • Enduring the stress of reality in time: Will the software support the load? Will it fail? What will happen then? Can we mitigate against this? The problem lies in the view that systems can be planned and control from the initial pool of information, a la the Plato story from my own talks! This has led to waterfall methodologies - research and plan enough so your software will be formally designed.

In the early 2000s, it was acknowledged that the initial view was only a partial understanding of the system’s input and so agile methodologies were gradually defined. The aim here was to iterate as often as you can so as to correct your path early.

Although a foot in the direction, this did not pan out as well as one could have hoped for. Indeed, changes could be introduced during the life of the project, but they still could take a long time to be delivered into production. This was the Elephant in the Standup effect; where your software becomes grossly in conflict with reality over time.
​

It's time for this to change. Right now the process can absorb incoming changes but the software, something you might hope would be wonderfully malleable, resists these changes.

If we don't architect and design to thrive on change then we are destined to build systems that will be perceved to be holding the business back.

We need to fix the software design and architecture, not just the process. This is at the heart of Antifragile Software as enabled by microservices.
Read more articles
0 Comments



Leave a Reply.

    Musings on software development

    Archives

    September 2017
    June 2017
    November 2016
    September 2016
    May 2016
    February 2016
    September 2015
    August 2015
    June 2015
    March 2015
    January 2015
    December 2014
    November 2014
    October 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    December 2013
    August 2013

    Categories

    All
    Announcements
    Antifragile
    Books
    Innovation
    Life Preserver
    Microservices
    Philosophy
    Psychology
    Reviews
    Software

    RSS Feed

Products

EBooks
​(Print) Books
Consultancy
Training
​
Speaking

Company

Essais
FAQ
Client feedback
Gallery

Support

Contact
Picture
© COPYRIGHT 2018. ALL RIGHTS RESERVED.


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.