#Issue19
3 posts

How is software developed at Amazon?

Decompose a monolithic organization into small, autonomous teams that own each service or product end to end. Automate as much as possible. Deploy in a pessimistic fashion, constantly looking for problems.
Read more

How is software developed at Amazon?

Key tenets Amazon follows to ensure its obsessive customer focus:

  • Decompose a monolithic organization into small, autonomous teams that own each service or product end to end.
  • Deploy in a pessimistic fashion, constantly looking for problems.
  • Deploy on a small scale, so that you can rollback in case of failure and expand only if successful.
  • Start every project with a threat model and have it reviewed by a security engineer; also seek peer feedback before committing to a build.
  • Architects do not develop the architecture of a project; developers on each team do.
  • Plan from the bottom up, because teams closest to the product know best what the customer wants.
  • Accept that keeping teams independent can result in occasional duplication.

Full video here, 41 mins watch time

How cognitive biases influence software development

It is a logical fallacy to assume chronology (X came before Y) indicates causality (Y happened because of X). Avoid confirmation bias by focusing more on what can go wrong than on what you are sure is right.
Read more

How cognitive biases influence software development

  • Anchoring effect (prior information used to make a decision that really should not depend on this given information): counter it by visualizing relevant data instead of relying on an anchor.
  • It is a logical fallacy to assume chronology (X came before Y) indicates causality (Y happened because of X).
  • Avoid confirmation bias by focusing more on what can go wrong than on what you are sure is right.
  • Pre-empt inattentional blindness by using checklists.
  • Authority bias: Just because someone trustworthy puts out a piece of information, does not mean you need to act on it or use it. The ‘authority’ can also be a specification document, or even yourself. Question all assumptions.

Full post here, 6 mins read time

Why is making software so difficult?

Business objectives can be messy: assumptions behind them can be wrong or there may be confusion about the objectives themselves. Project lifecycles can vary immensely and may become unpredictable.
Read more

Why is making software so difficult?

  • Business objectives can be messy: assumptions behind them can be wrong or there may be confusion about the objectives themselves.
  • Project lifecycles can vary immensely and may become unpredictable.
  • Software development often relies on stitching together existing tools and libraries. It can be difficult to see beforehand whether the chosen tools are actually suitable for the job.
  • Refining project specifications is harder because software is abstract.
  • Often, the person commissioning the project does not know what the solution should look like. Specifications are fuzzy at best.
  • It is up to the developer to articulate a solution and see whether it fits the expectations. It is not just a logical activity, it requires creative problem-solving.

Full post here, 10 mins read time