Engineering Practices

4 minute read

Adding people to a late software project makes it later. - Frederick Brooks (More about Brooks’s Law)

Practice What is it?
Spike
 
 
 		 Spike is an exploration (enabler story) around a technical issue that the team is uncertain and won’t be able to estimate the story or even can end up in a blocker. Spikes can not be estimated, but can be timeboxed.
  • Spikes (by SAFe)
  • What is Spike in Scrum?
  • Don’t estimate Spikes in Agile
    		•
    PoC
         		 (Proof of Concept)
    Is it feasible? That is the answer that we try to answer with a PoC. A PoC is typically an experiment or a small project that demonstrates that something is technically feasible. Also it is a way to learn and share knowledge with others since Engineers commonly present the PoC to other engineers.
    Premortem
     
         		 What could go wrong? If it failed what could have gone wrong? That is the answer that we try to answer with this practice. In other words, before we start to develop something we get together and discuss possible scenarios that could go wrong (if the server crashes, if the user tries to operate in a different way). This helps to have a more clear idea of the technical breakdown (the tasks we need to accomplish our goal) and reduce the later effort for operations and fixes)
  • Performing a Project Premortem (by Atlassian)
  • Conducting a Pre-Mortem (by Johns Hopkins University)
    		•
    Postmortem
     
     
         		 What went wrong? That is the answer that we try to answer with this practice. The idea is not to blame someone, but to find we we could have done to prevent the problem. In the end the objective is to identify what tasks should be accomplished to avoiding the problem to occur again. Those tasks can be related to software and infrastructure or even some new orientations in our Playbook.
  • Postmortem Culture: Learning from Failure (by Google)
  • Example Postmortem (by Google)
  • Blameless Postmortems - Examining Failure Without Blame
    		•
    Pair Programming
     
         		 When Sofware Engineers work together sharing the same screen and take turns on the keyboard. The main purpose of it is to share knowledge.
  • On Pair Programming (on Martin Fowler Blog)
  • Pair Programming Explained (by Shopify)
    		•
    Code Review
     
     
     
         		 When one or more Software Engineers reviews their team member’s code. The main purpose of it is to grant code quality, but also works as a way of less experienced engineers get coached by more experienced engineers.
  • Google’s Code Review Guidelines (by Google)
  • How to do a code review (by Google)
  • What to look for in a code review (by Google)
  • Effective Code Reviews
    		•
    Refactoring
     
         		 According to book Refactoring (by Martin Fowler): “Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each refactoring, reducing the chances that a system can get seriously broken during the restructuring.”
  • Refactoring Guru
  • Refactoring - Site of the book Refactoring (by Martin Fowler)
    		•
    Continuous Delivery soon
    Continuous Integration soon
    Observability soon
    Reliability soon

    References

    		 The Manager’s Path - by Camille Frontier
    A Guide for Tech Leaders Navigating Growth and Change
    Key takeaways
  • “One-on-one meetings with your manager are an essential feature of a good working relationship.”
  • “A manager’s job involves making it easy for her employees to get things done by creating fertile environments in which work can happen.”
  • “Mentoring new hires is critical.”
  • “Feedback works best when you, as a manager, pair that feedback with coaching.”
  • “It’s unrealistic to think you can or should shield your team from everything.”
    		•
    		Production-Ready Microservices - by Susan Fowler
    Building Standardized Systems Across an Engineering Organization
    		Microservices Patterns - by Chris Richardson
    		Refactoring - by Martin Fowler
    Improving the Design of Existing Code