Principles from software development
- Principles from software development
- 5 Whys
- Brooks's law
- Fail fast
- Imperative vs Declarative style of programming
- Minimum viable product
- Pareto principle
- Pastel's law
- Rubber duck debugging
- The next action
- The twelve-factor app
- The Zen of Python
The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question "Why?" Each question forms the basis of the next question. The "5" in the name derives from an empirical observation on the number of iterations typically required to resolve the problem.
The technique was formally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies.
The benefits of asking why (according to GTD):
- it defines success
- it creates decision-making criteria
- it aligns resources
- it motivates
- it clarifies focus
- it expands options
An After Action Review is a structured review or de-brief process for analyzing what happened, why it happened, and how it can be done better.
To apply this tool ask yourself:
- What was supposed to happen?
- What did happen?
- What are some improvements?
- What are some sustainments?
- What can be done to improve the result?
Adding manpower to a late software project makes it later.
Don’t repeat yourself.
A software engineering principle stating that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." It first appeared in the book The Pragmatic Programmer by Andy Hunt and Dave Thomas.
Easier to ask for forgiveness than permission.
try: x = my_dict["key"] except KeyError: # say sorry
A system design approach recommending that errors should be reported as early as possible.
Imperative vs Declarative style of programming
Declarative style of programming tells a computer what to do without specifying how, while an imperative style style of programming describes how to do it.
Stands for "Keep It Simple, Stupid."
Simplest solution is often the best.
This calls for seeking the simplest possible solution, with the fewest moving parts. The phrase was coined by Kelly Johnson, a highly accomplished aerospace engineer who worked in the real Area 51 designing some of the most advanced aircraft of the 20th centure.
Minimum viable product
MVP is the product with the highest return on investment versus risk. It is the sweet spot between products without the required features that fail at sunrise and the products with too many features that cut return and increase risk. The term was coined and defined by Frank Robinson, and popularized by Steve Blank, and Eric Ries.
The first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP). The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.
A programming paradigm based on the concept of "objects", which are data structures that contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods.
There are four main principles:
Code smell - a symptom of bad OO design.
In programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:
- A language mechanism for restricting access to some of the object's components.
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
Abstraction is a technique for managing complexity of computer systems. It works by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details below the current level.
[We] started to push on the inheritance idea as a way to let novices build on frameworks that could only be designed by experts.
Alan Kay, The Early History of Smalltalk
Inheritance is when an object or class is based on another object (prototypal inheritance) or class (class-based inheritance), using the same implementation (inheriting from an object or class) specifying implementation to maintain the same behavior (realizing an interface; inheriting behavior).
For many events, roughly 80% of the effects come from 20% of the causes.
Or robustness principle.
Be conservative in what you do, be liberal in what you accept from others.
Rubber duck debugging
Rubber duck debugging is an informal term used in software engineering for a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.
Single responsibility (SRP)
Gather together those things that change for the same reason, and separate those things that change for different reasons.
Robert C. Martin, Single Responsibility Principle
According to Wikipedia:
In object-oriented programming, the single responsibility principle states that every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Liskov substitution (LCP)
States that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.)
Interface segregation (ISP)
ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
Dependency inversion (DIP)
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
Test-driven design (also seen test-driven development).
The next action
A powerful principle from GTD technique: Next action must be defined.
The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small, manageable tasks, and then starting on the first one.
Next action - the next physical, visible activity that progress something toward completion. It is specific enough so that you know where it happens, and with what tools (if any). What "doing" looks like.
The twelve-factor app
The twelve-factor app is a methodology for building software-as-a-service apps.
The Zen of Python
PEP-20 by Tim Peters:
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one - and preferably only one - obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea - let's do more of those!
Stands for "You Ain't Gonna Need It."
A slogan to avoid implementing functionality that is not immediately necessary based on assumptions about future needs.