Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
Software Architecture, Process and Management (In The Real World) Mike McQuaid
Slide 2
Slide 2 text
who are you?
Slide 3
Slide 3 text
Mike McQuaid @MikeMcQuaid
[email protected]
Software Engineer
Slide 4
Slide 4 text
why should we listen to you?
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
Summer 2006
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
2007-8
Slide 9
Slide 9 text
2008-9
Slide 10
Slide 10 text
2009-12
Slide 11
Slide 11 text
2012-13
Slide 12
Slide 12 text
2013-?
Slide 13
Slide 13 text
Homebrew https://github.com/Homebrew/homebrew 2009-?
Slide 14
Slide 14 text
introduction
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
http://blog.codinghorror.com http://joelonsoftware.com http://randsinrepose.com http://thedailywtf.com
Slide 17
Slide 17 text
formal project management
Slide 18
Slide 18 text
Beware “Software Architects”
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
i.e. not doing the work but telling others what to do
Slide 21
Slide 21 text
Beware “Software Architecture”
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
the only Formal Project Management process that actually works
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
On Time ! ! !
Slide 26
Slide 26 text
On Time Good Quality ! !
Slide 27
Slide 27 text
On Time Good Quality Feature Complete !
Slide 28
Slide 28 text
On Time Good Quality Feature Complete Pick 2
Slide 29
Slide 29 text
On Time Good Quality Feature Complete Pick 2 (or 1, 0)
Slide 30
Slide 30 text
tools for software projects
Slide 31
Slide 31 text
No content
Slide 32
Slide 32 text
proprietary version control systems are (usually) awful
Slide 33
Slide 33 text
brew install git git init git commit
Slide 34
Slide 34 text
embrace laziness
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
your build process should be:
Slide 37
Slide 37 text
your build process should be: make
Slide 38
Slide 38 text
your test process should be: make
Slide 39
Slide 39 text
your deploy process should be: make
Slide 40
Slide 40 text
your release process should be: make
Slide 41
Slide 41 text
automated tests
Slide 42
Slide 42 text
automated packaging
Slide 43
Slide 43 text
automated deployment
Slide 44
Slide 44 text
documentation is a code smell
Slide 45
Slide 45 text
// The aperture size int a = 3;
Slide 46
Slide 46 text
! int aperture_size = 3;
Slide 47
Slide 47 text
/** * @return Returns the xyz. */ public String getXyz() { return xyz; }
Slide 48
Slide 48 text
/** * @param xyz The xyz to set. */ public void setXyz(String xyz) { this.xyz = xyz; }
Slide 49
Slide 49 text
if you don’t code in your interview you might suck
Slide 50
Slide 50 text
if you don’t code in your interview some coworkers will suck
Slide 51
Slide 51 text
No content
Slide 52
Slide 52 text
estimating size and effort
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
everyone sucks at estimation
Slide 55
Slide 55 text
learn from your own mistakes
Slide 56
Slide 56 text
About dialog modality is wrong ! Issue #12345 Estimated: 4 hours Actual: 0 hours
Slide 57
Slide 57 text
Try and fix about dialog modality ! [#12345 6h] !
Slide 58
Slide 58 text
About dialog modality is wrong ! Issue #12345 Estimated: 4 hours Actual: 6 hours
Slide 59
Slide 59 text
Actually fix about dialog modality ! [#12345 8h] !
Slide 60
Slide 60 text
About dialog modality is wrong ! Issue #12345 Estimated: 4 hours Actual: 14 hours
Slide 61
Slide 61 text
universally hated
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
best/likely/worst case estimations
Slide 64
Slide 64 text
disappoint now or later?
Slide 65
Slide 65 text
measuring software
Slide 66
Slide 66 text
measure velocity
Slide 67
Slide 67 text
measure compiler warnings
Slide 68
Slide 68 text
measure test coverage
Slide 69
Slide 69 text
measure lint failures
Slide 70
Slide 70 text
software development methodologies
Slide 71
Slide 71 text
the only winning move is not to play
Slide 72
Slide 72 text
the best methodology is a pragmatic mush
Slide 73
Slide 73 text
waterfall is nearly always the worst possible idea
Slide 74
Slide 74 text
agile (not Agile™©®) is basically common sense
Slide 75
Slide 75 text
ship early and often
Slide 76
Slide 76 text
strict process == broken team
Slide 77
Slide 77 text
strict process == rubbish engineers
Slide 78
Slide 78 text
XP is good
Slide 79
Slide 79 text
always be releasable
Slide 80
Slide 80 text
to get nothing done work more than 40 hours
Slide 81
Slide 81 text
pair programming increases quality
Slide 82
Slide 82 text
pair programming increases boredom
Slide 83
Slide 83 text
best projects involve glue
Slide 84
Slide 84 text
design patterns
Slide 85
Slide 85 text
worth knowing worth considering
Slide 86
Slide 86 text
be as DRY as possible
Slide 87
Slide 87 text
architectural patterns
Slide 88
Slide 88 text
software development is not like building a bridge
Slide 89
Slide 89 text
read about the architecture of open-source software
Slide 90
Slide 90 text
scripting
Slide 91
Slide 91 text
unit tests are compilers for dynamic languages
Slide 92
Slide 92 text
dynamic languages are DRYer
Slide 93
Slide 93 text
pick the right language for the job
Slide 94
Slide 94 text
software failures
Slide 95
Slide 95 text
or: software
Slide 96
Slide 96 text
huge teams huge systems huge failures
Slide 97
Slide 97 text
small teams small systems small failures
Slide 98
Slide 98 text
failure == not solving the problem
Slide 99
Slide 99 text
risk management
Slide 100
Slide 100 text
small teams small systems small failures
Slide 101
Slide 101 text
always shippable state
Slide 102
Slide 102 text
software evolution
Slide 103
Slide 103 text
don’t change weird code unless you understand why it is weird
Slide 104
Slide 104 text
No content
Slide 105
Slide 105 text
lots of bad code solving problems
Slide 106
Slide 106 text
lots of good code unused
Slide 107
Slide 107 text
complexity is the enemy of quality
Slide 108
Slide 108 text
only refactor with good test coverage
Slide 109
Slide 109 text
only refactor with 100% test coverage
Slide 110
Slide 110 text
avoid all technical debt
Slide 111
Slide 111 text
open source development
Slide 112
Slide 112 text
Homebrew
Slide 113
Slide 113 text
open source code vs open source projects
Slide 114
Slide 114 text
people and groups
Slide 115
Slide 115 text
GitHub
Slide 116
Slide 116 text
working remote
Slide 117
Slide 117 text
No content
Slide 118
Slide 118 text
remote communication
Slide 119
Slide 119 text
asynchronous communication
Slide 120
Slide 120 text
written communication
Slide 121
Slide 121 text
No content
Slide 122
Slide 122 text
! no management
Slide 123
Slide 123 text
no (formal) management
Slide 124
Slide 124 text
good management == persuasion
Slide 125
Slide 125 text
conclusion
Slide 126
Slide 126 text
fail quickly understand lots automate everything
Slide 127
Slide 127 text
No content
Slide 128
Slide 128 text
…what?