Book: Building Evolutionary Architectures

Had this book for some time, just took a while to write up my notes 🙂

• Page 7, Fitness Functions – objective function used to summarise how close a prospective design solution is to achieving the set aims
• Page 12, structure of teams around service boundaries.
• Page 35, QA in Production.  I’ve used this over the last n years, to great effect 🙂
• Page 36, Chaos Monkey, Simian Army, and Conformity Monkey.  Design with Chaos Monkey in mind to ensure architectures have resilience built in from day 1 🙂  Conformity Monkey checks services to ensure they follow architect-defined best practices.
• Hypothesis driven UX design
• Page 48, Domain-Driven Design.  Forget the unified class across all services concept.  Allow each service to define their own, and reconcile differences at integration points (bounded context)
• Page 96, Use Deployment Pipelines to Automate Fitness Functions.  Cycle Time is the measure of engineering efficiency.
• Page 98, the biggest single common impediment to building evolutionary architecture is intractable operations.
• Page 128, Anti-pattern – Code Reuse Abuse
• Page 131, Pitfall – Resume-Driven Development.  We’ll all seen this one
• Page 133, Forced Decoupling
• Page 133, Goldilocks Governance model – pick three technology stacks for standardisation: Simple, intermediate and complex.
• Page 144, Product over project 🙂  Like this concept a lot 🙂
• Page 154, Testing.  Obvious, but constantly needs to be re-iterated 😦

Great book.  Sensible length.  Easy to consume 🙂

Agile – The ambiguous word

These days everyone is “agile” – well almost 🙂  Like most things, the world isn’t that simple when it comes to agile.  We have coaches getting certified, and believing they are now fully agile, and we have multiple agile process that an organisation could consider in their agile pursuits:

• Scrum
• SAFe
• LeSS
• Nexus
• Nexus+
• Spotify Model

Deciding which process to follow is going to be difficult.  Everyone has a view, and is an expert.  Whatever process you decide to follow, keep in mind the following:

• Value – Delivering value in terms of priority
• Quality – Though story acceptance
• Metrics – Measure cycle time

Incident Management

Great talk on InfoQ from Netflix discussing a framework to handle incidents.

• Don’t use Post Mortem’s as nobody has died
• Incidents are complex, expensive, and generate unplanned work (tech and org)
• Guardrails over control/restrictions e.g. its the busiest time of the data to do a code push, are you sure?
• Incident Management Goals – 22 mins into the video
• Gamification of Incident Management – 24mins
• Framework used by Netflix Core Site Reliability Engineers Team
  • Engagement
  • Communication
  • Coordination
  • Memorialisation
• Before incidents
  • Education – “Failing well” course, change rates, velocity of innovation
  • Best Practices
  • Drilling
• Reprioritisation of work post an incident to avoid further incidents
• Stop saying “Human Error”
• Degraded is Normal
• Constant Failure
• Any change is a gamble
• Measuring Success
  • Short & Less Impact
  • More Incidents
  • Better Team Engagement

Cryptocurrency Exchange Platform

Worth a read if your about to build a cryptocurrency exchange platforM:

• How To Develop A Cryptocurrency Exchange Platform
• How To Start Your Bitcoin Exchange – A Beginner’s Guide
• Design Principles & Risk Management

Agile Testing – Moving out of the Comfort Zone

“Hurricane Mike: Urciuoli Storms JPMorgan Asset & Wealth Management” is a great read on what it takes to change the culture of a large organisation.

Resistance is expected on such a path.

Solution – fly the “entire management team” to the West Coast, so that management grasped the concept and benefits of agile, “automated testing and unit test code coverage, rather than relying on feedback from groups of manual users.”

Game Changer 🙂

Centre of Expertise Software Development: Shift Left

Looks like ABN AMRO is embracing software quality 🙂

“Introduction:Happy flow programming is easy, taking into account everything that can go wrong is difficult. There are many theories on how to properly take into account non-functional requirements such as maintainability, reliability in early stages of the software development life cycle. Shift left testing is an approach to software testing and system testing in which testing is performed earlier in the lifecycle (i.e., moved left on the project timeline). It is the first half of the maxim “Test early and often.“ Why is it that transferring these theories into practice is so hard? What is it that more often than not a software engineer does not tackle what can go wrong earlier in the process? Problem:ABN AMRO has a long history in software development and certain processes and procedures have become habits. For instance validating quality at a very late stage, by having the bulk of tests in the acceptance environment. Although most stakeholders are aware of this and see the need to move a lot of this work to the development and test phases, the pace of adoption and practical implementations is still too low. Research questions:The main problem is the adoption of proper testing at development time. As a result, the main research question is:What are the best practices for shifting as many tests as possible to the development phase? Other underlying research questions might be:

How can the quality of Unit Tests be validated and improved?
How can performance tests be implemented in the development or test phase?
How can availability tests be implemented in the development or test phase?”

Actionable Metrics

I’ve always been a fan of Kanban.  Actionable Agile provide an interesting read on how actionable flow metrics (Work In Progress, Cycle Time, Throughput) are used to reduced Cycle Times, which leads to faster delivery of business value stories to the end users 🙂

Finally,  “no more estimation” (story points) using instead predictability 🙂