Software Architecture, Process and Management (In the Real World)

How software architecture, process and management plays out in the real world with some best practices and things to avoid.
Presented as a guest lecture at The University of Edinburgh's Software Architecture, Process and Management course in 2014.

Transcript

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