From UNIX to today
2 min read
do one thing and do it well
handle text streams, because that is a universal interface
- easily maintainable
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
plan before coding
keep it simple
do not optimize early
Measure. Don’t tune for speed until you’ve measured
do one thing well
So much complexity in software comes from trying to make one thing do two things.
first, make it work, then make it faster
keep it simple
you ain’t gonna need it
Perfect is the enemy of good
If it ain’t broke, don’t fix it
Gold plating, Nirvana fallacy, over engineering
KISS keep it simple, stupid
Define must - should - could -won’t
The simplest thing that could possibly work
“The cheapest, fastest, and most reliable components are those that aren’t there.” – Gordon Bell
Hide complexity Selectively reveal
“Only amateurs attack machines; professionals target people.” – Bruce Schneier
Security at the expense of usability comes at the expense of security.
“By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback.” – Kent Beck
“Real artists ship.” – Steve Jobs
Anything that works is better than anything that doesn’t
The most important input to this learning is customer feedback, deliver working software to customers early & often.
Brooks’s law: Adding manpower to a late software project makes it later.
Too much work in progress causes problems.
Always back everything up! Accept responsibility for your own mistakes. And never make changes in production!
“As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.” – David Parnas
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work.” – John Gall
Question your assumptions. Bad assumptions cause bugs.
If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident.
Ask For Feedback Early
Get End-to-End First
Step Away From the Keyboard
You Can DRY Off Later
no deploy fridays
Take Meticulous Notes
January 15, 2020