DEV Community

Arpit Mohan
Arpit Mohan

Posted on • Originally published at

The Amazon way; why making software is hard; & tricks our brain plays

My TL;DR style notes from articles I read today.

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

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

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

I share these TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up here if you liked what you just read.

Top comments (0)