building better tools

88
Building Better Tools Slide 1 Building Better Tools Jan Schaumann [email protected] 136D 027F DC29 8402 7B42 47D6 7C5B 64AF AF22 6A4C Jan Schaumann June 3, 2009

Upload: jan-schaumann

Post on 30-May-2015

590 views

Category:

Technology


0 download

DESCRIPTION

A talk on how system engineers and administrators, the people who maintain the infrastructure of the internet and who write a lot of code without (usually) having any training in software engineering practices, can improve their tools. Originally given at NYCBug in June 2009.

TRANSCRIPT

Page 1: Building better tools

Building Better Tools Slide 1

Building Better Tools

Jan [email protected]

136D 027F DC29 8402 7B42 47D6 7C5B 64AF AF22 6A4C

Jan Schaumann June 3, 2009

Page 2: Building better tools

Building Better Tools Slide 2

whoami

$ groups

netbsd yahoo

$

Jan Schaumann June 3, 2009

Page 3: Building better tools

Building Better Tools Slide 3

whoami

$ groups

netbsd yahoo

$

Jan Schaumann June 3, 2009

Page 4: Building better tools

Building Better Tools Slide 4

whoami

$ groups

netbsd yahoo

$

Jan Schaumann June 3, 2009

Page 5: Building better tools

Building Better Tools Slide 5

A much better way to spend your time.

Jan Schaumann June 3, 2009

Page 6: Building better tools

Building Better Tools Slide 6

People think the internet looks like this.

Jan Schaumann June 3, 2009

Page 7: Building better tools

Building Better Tools Slide 7

In reality...

Jan Schaumann June 3, 2009

Page 8: Building better tools

Building Better Tools Slide 8

Tools

Jan Schaumann June 3, 2009

Page 9: Building better tools

Building Better Tools Slide 9

The right tool?

Jan Schaumann June 3, 2009

Page 10: Building better tools

Building Better Tools Slide 10

The right tool?

Jan Schaumann June 3, 2009

Page 11: Building better tools

Building Better Tools Slide 11

The right tool?

Jan Schaumann June 3, 2009

Page 12: Building better tools

Building Better Tools Slide 12

The right tool?

Jan Schaumann June 3, 2009

Page 13: Building better tools

Building Better Tools Slide 13

Internet Reality

Jan Schaumann June 3, 2009

Page 14: Building better tools

Building Better Tools Slide 14

Sturgeon’s Revelation

90% of everything is crud.

Jan Schaumann June 3, 2009

Page 15: Building better tools

Building Better Tools Slide 15

A better hammer!

Jan Schaumann June 3, 2009

Page 16: Building better tools

Building Better Tools Slide 16

Tools Development

Three basic categories:

scripting

programming

software development

Jan Schaumann June 3, 2009

Page 17: Building better tools

Building Better Tools Slide 17

Tools Development

Three basic categories:

scripting

Jan Schaumann June 3, 2009

Page 18: Building better tools

Building Better Tools Slide 18

Tools Development

Three basic categories:

scripting

automating very simple tasks

Jan Schaumann June 3, 2009

Page 19: Building better tools

Building Better Tools Slide 19

Tools Development

Three basic categories:

scripting

automating very simple tasks

customization of user environment

Jan Schaumann June 3, 2009

Page 20: Building better tools

Building Better Tools Slide 20

Tools Development

Three basic categories:

scripting

automating very simple tasks

customization of user environment

often only suitable for one individual user

Jan Schaumann June 3, 2009

Page 21: Building better tools

Building Better Tools Slide 21

Tools Development

Three basic categories:

scripting

automating very simple tasks

customization of user environment

often only suitable for one individual user

usually eventually evolves into larger programs

Jan Schaumann June 3, 2009

Page 22: Building better tools

Building Better Tools Slide 22

Tools Development

Three basic categories:

programming

Jan Schaumann June 3, 2009

Page 23: Building better tools

Building Better Tools Slide 23

Tools Development

Three basic categories:

programming

Jan Schaumann June 3, 2009

Page 24: Building better tools

Building Better Tools Slide 24

Tools Development

Three basic categories:

programming

suitable for simple to moderately complex tasks

Jan Schaumann June 3, 2009

Page 25: Building better tools

Building Better Tools Slide 25

Tools Development

Three basic categories:

programming

suitable for simple to moderately complex tasks

results frequently used by a small base of users

Jan Schaumann June 3, 2009

Page 26: Building better tools

Building Better Tools Slide 26

Tools Development

Three basic categories:

programming

suitable for simple to moderately complex tasks

results frequently used by a small base of users

uses basic framework or common toolkits

Jan Schaumann June 3, 2009

Page 27: Building better tools

Building Better Tools Slide 27

Tools Development

Three basic categories:

programming

suitable for simple to moderately complex tasks

results frequently used by a small base of users

uses basic framework or common toolkits

provides consistent interface

Jan Schaumann June 3, 2009

Page 28: Building better tools

Building Better Tools Slide 28

Tools Development

Three basic categories:

programming

suitable for simple to moderately complex tasks

results frequently used by a small base of users

uses basic framework or common toolkits

provides consistent interface

may evolve into full product

Jan Schaumann June 3, 2009

Page 29: Building better tools

Building Better Tools Slide 29

Tools Development

Three basic categories:

software development

Felton Pilate, MC Hammer’s producer

Jan Schaumann June 3, 2009

Page 30: Building better tools

Building Better Tools Slide 30

Tools Development

Three basic categories:

software development

Jan Schaumann June 3, 2009

Page 31: Building better tools

Building Better Tools Slide 31

Tools Development

Three basic categories:

software development

required for any reasonably complex task

Jan Schaumann June 3, 2009

Page 32: Building better tools

Building Better Tools Slide 32

Tools Development

Three basic categories:

software development

required for any reasonably complex task

uses formal software engineering approach (measurable goals, requirements,specifications, ...)

Jan Schaumann June 3, 2009

Page 33: Building better tools

Building Better Tools Slide 33

Tools Development

Three basic categories:

software development

required for any reasonably complex task

uses formal software engineering approach (measurable goals, requirements,specifications, ...)

may evolve from previous prototypes

Jan Schaumann June 3, 2009

Page 34: Building better tools

Building Better Tools Slide 34

Tools Development

Three basic categories:

software development

required for any reasonably complex task

uses formal software engineering approach (measurable goals, requirements,specifications, ...)

may evolve from previous prototypes

requires ongoing continous maintenance / development efforts

Jan Schaumann June 3, 2009

Page 35: Building better tools

Building Better Tools Slide 35

Evolution of the programming systems product

F. Brooks, “The Mythical Man Month”

Jan Schaumann June 3, 2009

Page 36: Building better tools

Building Better Tools Slide 36

Evolution of the programming systems product

F. Brooks, “The Mythical Man Month”

Jan Schaumann June 3, 2009

Page 37: Building better tools

Building Better Tools Slide 37

“Trust me, I know what I’m doing.”

Jan Schaumann June 3, 2009

Page 38: Building better tools

Building Better Tools Slide 38

Documentation

“RTFM!”

Jan Schaumann June 3, 2009

Page 39: Building better tools

Building Better Tools Slide 39

Documentation

WTFM

Jan Schaumann June 3, 2009

Page 40: Building better tools

Building Better Tools Slide 40

User Interface

Jan Schaumann June 3, 2009

Page 41: Building better tools

Building Better Tools Slide 41

Unix Philosophy

Jan Schaumann June 3, 2009

Page 42: Building better tools

Building Better Tools Slide 42

Unix Philosophy

Do one thing and do it well.

Jan Schaumann June 3, 2009

Page 43: Building better tools

Building Better Tools Slide 43

The KISS Principle

Jan Schaumann June 3, 2009

Page 44: Building better tools

Building Better Tools Slide 44

POLA

Principle of Least Astonishment

Jan Schaumann June 3, 2009

Page 45: Building better tools

Building Better Tools Slide 45

Test Driven

Jan Schaumann June 3, 2009

Page 46: Building better tools

Building Better Tools Slide 46

The Zen of Python

Beautiful is better than ugly.

Jan Schaumann June 3, 2009

Page 47: Building better tools

Building Better Tools Slide 47

The Zen of Python

Explicit is better than implicit.

Jan Schaumann June 3, 2009

Page 48: Building better tools

Building Better Tools Slide 48

Explicit is better than implicit.

Autovivification is Evil!

$oink = { ’foo’ => { ’x’ => 1, },

’bar’ => { ’y’ => 2, },

} ;

if (exists($oink->{’baz’}{’z’})) {

print "oink->baz->z exists\n";

}

if (exists($oink->{’baz’})) {

print "oink->baz exists\n";

}

Jan Schaumann June 3, 2009

Page 49: Building better tools

Building Better Tools Slide 49

Explicit is better than implicit.

For $Deity’s sake, return something.

sub func {

my ($ref, $ref_or_is_it_something_else) = @_;

for my $a (@{$ref}) {

if (condition) {

return 1;

}

}

}

Jan Schaumann June 3, 2009

Page 50: Building better tools

Building Better Tools Slide 50

The Zen of Python

Simple is better than complex.

http://xkcd.com/399/

Jan Schaumann June 3, 2009

Page 51: Building better tools

Building Better Tools Slide 51

The Zen of Python

Complex is better than complicated.

Jan Schaumann June 3, 2009

Page 52: Building better tools

Building Better Tools Slide 52

The Zen of Python

Flat is better than nested.

Jan Schaumann June 3, 2009

Page 53: Building better tools

Building Better Tools Slide 53

The Zen of Python

Sparse is better than dense.

Jan Schaumann June 3, 2009

Page 54: Building better tools

Building Better Tools Slide 54

The Zen of Python

Readability counts.

Jan Schaumann June 3, 2009

Page 55: Building better tools

Building Better Tools Slide 55

The Zen of Python

Special cases aren’t special enough to break the rules.

Jan Schaumann June 3, 2009

Page 56: Building better tools

Building Better Tools Slide 56

The Zen of Python

Special cases aren’t special enough to break the rules.

Although practicality beats purity.

Jan Schaumann June 3, 2009

Page 57: Building better tools

Building Better Tools Slide 57

The Zen of Python

Special cases aren’t special enough to break the rules.

Although practicality beats purity.

Sturgeon’s Law: Nothing is always absolutely so.

Jan Schaumann June 3, 2009

Page 58: Building better tools

Building Better Tools Slide 58

The Zen of Python

Errors should never pass silently.

Jan Schaumann June 3, 2009

Page 59: Building better tools

Building Better Tools Slide 59

The Zen of Python

Errors should never pass silently.(That would be implicitly accepted failure.)

Jan Schaumann June 3, 2009

Page 60: Building better tools

Building Better Tools Slide 60

The Zen of Python

Errors should never pass silently.(That would be implicitly accepted failure.)

(You know what would be better than something implicit?)

Jan Schaumann June 3, 2009

Page 61: Building better tools

Building Better Tools Slide 61

The Zen of Python

Errors should never pass silently.(That would be implicitly accepted failure.)

(You know what would be better than something implicit?)

(Why, of course, something explicit!)

Jan Schaumann June 3, 2009

Page 62: Building better tools

Building Better Tools Slide 62

The Zen of Python

Errors should never pass silently.

Unless explicitly silenced.

Jan Schaumann June 3, 2009

Page 63: Building better tools

Building Better Tools Slide 63

The Zen of Python

In the face of ambiguity, refuse the temptation to guess.

Jan Schaumann June 3, 2009

Page 64: Building better tools

Building Better Tools Slide 64

The Zen of Python

There should be one – and preferably only one – obviousway to do it.

Jan Schaumann June 3, 2009

Page 65: Building better tools

Building Better Tools Slide 65

The Zen of Python

There should be one – and preferably only one – obviousway to do it.

Although that way may not be obvious at first unless you’reDutch.

Jan Schaumann June 3, 2009

Page 66: Building better tools

Building Better Tools Slide 66

The Zen of Python

Now is better than never.

Jan Schaumann June 3, 2009

Page 67: Building better tools

Building Better Tools Slide 67

The Zen of Python

Now is better than never.

Although never is often better than right now.

Jan Schaumann June 3, 2009

Page 68: Building better tools

Building Better Tools Slide 68

The Zen of Python

If the implementation is hard to explain, it’s a bad idea.

Jan Schaumann June 3, 2009

Page 69: Building better tools

Building Better Tools Slide 69

The Zen of Python

If the implementation is easy to explain,it may be a good idea.

Jan Schaumann June 3, 2009

Page 70: Building better tools

Building Better Tools Slide 70

A simple interface, easy to explain. Yet...

Jan Schaumann June 3, 2009

Page 71: Building better tools

Building Better Tools Slide 71

The Zen of Python

Namespaces are one honking great idea –let’s do more of those!

Jan Schaumann June 3, 2009

Page 72: Building better tools

Building Better Tools Slide 72

Consistency

Jan Schaumann June 3, 2009

Page 73: Building better tools

Building Better Tools Slide 73

Robustness Principle or Postel’s Law

Be conservative in what you do; be liberal in what youaccept from others.

Jan Schaumann June 3, 2009

Page 74: Building better tools

Building Better Tools Slide 74

Toss it!

Jan Schaumann June 3, 2009

Page 75: Building better tools

Building Better Tools Slide 75

Avoid the Quick Fix

There’s nothing as permanent as a temporary solution.

Jan Schaumann June 3, 2009

Page 76: Building better tools

Building Better Tools Slide 76

Take a good look in the mirror!

Nice Ass!

Jan Schaumann June 3, 2009

Page 77: Building better tools

Building Better Tools Slide 77

Take a good look in the mirror!

Until you can prove otherwise,assume that you are an Ass!

Jan Schaumann June 3, 2009

Page 78: Building better tools

Building Better Tools Slide 78

Don’t try to be clever!

insert

clever sentence or image about how trying to be

clever increases complexity and leads to code that

is difficult to understand

here

Jan Schaumann June 3, 2009

Page 79: Building better tools

Building Better Tools Slide 79

Avoid the Project That Was Never Finished

Don’t let the Perfect be the enemy of the Good.

Jan Schaumann June 3, 2009

Page 80: Building better tools

Building Better Tools Slide 80

Avoid Feature Creep

http://www.feepingcreatures.com

Jan Schaumann June 3, 2009

Page 81: Building better tools

Building Better Tools Slide 81

Release Early, Release Often

“More users find more bugs.”F. Brooks, “The Mythical Man Month”

Jan Schaumann June 3, 2009

Page 82: Building better tools

Building Better Tools Slide 82

Increase the Bus Factor

“Just friends.”

Jan Schaumann June 3, 2009

Page 83: Building better tools

Building Better Tools Slide 83

Fix Broken Windows

Jan Schaumann June 3, 2009

Page 84: Building better tools

Building Better Tools Slide 84

Program Maintenance

“... is an entropy-increasing process, and even its mostskillful execution only delays the subsidence of the system

into unfixable obsolescence.”F. Brooks, “The Mythical Man Month”

Jan Schaumann June 3, 2009

Page 85: Building better tools

Building Better Tools Slide 85

Toss it!

Jan Schaumann June 3, 2009

Page 86: Building better tools

Building Better Tools Slide 86

Starting fresh

Jan Schaumann June 3, 2009

Page 87: Building better tools

Building Better Tools Slide 87

Ownership

Jan Schaumann June 3, 2009

Page 88: Building better tools

Building Better Tools Slide 88

Done!

Jan Schaumann June 3, 2009