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)