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.