Removing uncertainty the tip of the iceberg

26-11-2022

  • url: https://theengineeringmanager.substack.com/p/removing-uncertainty-the-tip-of-the
  • software as an iceberg
    • good software is like an iceberg, the tip is visible and beautiful but most of it exists underwater
    • working on things no one else sees
    • inverse relationship between delight of user experience and challenge of implementation at scale
    • scale increases iceberg
    • better design makes it look more simple
  • managing expectations is difficult
    • design is simple, but requires lots of work
    • estimates are difficult
    • how to prevent producing no visible work
    • lack strategy rather than skills
  • the goal is reducing uncertainty
    • align team around continually reducing uncertainty
    • prototyping, designing, writing code, shipping all reduce uncertainty
    • when you have zero uncertainty the feature has shipped
    • this builds momentum and trust inside and outside of the team
    • stripping uncertainty backs the contracts that you have
    • the most uncertain parts have the biggest probability of blowing up in scope and complexity, don't leave for last
  • how to reduce uncertainty
    • defining the problem and metrics for success
    • prototype
      • what are the success metrics for a project
      • don't wait until you build something
        • use low-code and no-code solutions, get eyes on your thinking
      • don't leave prototyping to the user facing products, this can be applied to anything (ie database schemas, dummy data)
    • build
      • establish clear interfaces and contracts
        • make clear what is expected from various parts of the system upfront
        • API request and response models
        • non-functional requirements like performance and possible trade-offs
      • static data to replace complex backends
        • a large backend may leave frontend engineers waiting, instead serve static JSON so they can get a feel for things
      • high fidelity mock-ups
    • launch
      • feature flags
        • A/B testing, beta groups
        • merge changes into main earlier (preventing large chains of code changes)
        • having an architecture that fits feature flags is also powerful
      • shadow deployments
        • big difference between development environment and production environments
          • users, traffic, data
        • deploy backend system into production and route traffic towards it
          • measure both ingress and egress paths, observe load
          • users don't even know it's there
  • standing on the shoulder of giants
    • most productive time for shipping additions and improvements is within 6-12 months
    • code is new, context and kinetic energy is high, rich backlog of ideas
    • some orgs want to move on quickly, but most predictable and impactful work can be done right after shipping