Contents
Chapter 1 People’s Accountability 1
1.1 Responsibility card 2
1.2 Code ownership 4
1.3 The produce-review cycle 4
1.4 The indifferent customer 5
Chapter 2 Building Teams 6
2.1 Stating vision 6
2.2 Starting small 6
2.3 Characteristics of a quality software engineer 7
2.4 Software health 7
2.5 Being honest about development status 8
2.6 Treasuring old code 8
2.7 Meeting 8
2.8 Who makes the final decision? 9
2.9 Bus factor 9
2.10 Joel test 10
2.11 Evaluating team quality from four aspects 11
2.12 Measuring productivity 12
2.13 Training and employee retention rate 12
2.14 Improving software process 13
2.15 Data and statistics 13
2.16 Territory 13
2.17 Code review 13
2.17.1 Pull request 14
2.17.2 Code review plus edit 16
2.17.3 Code review psychology 18
2.18 Treating criticism as praise 19
2.19 Automation ratio 19
2.20 Code of conduct 20
2.21 Software principles 20
2.22 Roles 22
2.23 Development time distribution 23
2.24 Comment to code ratio 24
2.25 The Apache Way 24
2.26 Intellectual property and licenses 25
2.27 Documentation 25
2.27.1 Being easy to find, easy to search, and easy to update 26
2.27.2 Being specific 26
2.27.3 Providing links wherever available 27
2.27.4 Documenting everything 27
2.27.5 Learning from good examples 27
2.27.6 Inspecting documentation 28
Chapter 3 Reducing Complexity, Increasing Quality 29
3.1 Source lines of code 29
3.2 Say no to bloatware 30
3.3 Software quality 32
3.4 High quality is cheap 32
3.5 Refactoring code 33
Chapter 4 Cloud Infrastructure 35
4.1 The pull request-centered collaboration model 36
4.2 Remote working 37
4.3 Email 39
4.4 Mailing lists 40
4.5 Git and GitHub 41
4.5.1 The feature-branching workflow 42
4.5.2 The fork-then-feature-branching workflow 47
4.5.3 Gitea 48
4.6 Kanboard 49
4.7 Bugzilla 51
4.7.1 Tracked bugs are good bugs 52
4.7.2 The more bug reports, the better 52
4.7.3 Do not accept duplicate bugs 53
4.8 The Bugzilla-Kanboard-Gitea workflow 53
4.9 Jenkins 55
Chapter 5 Selected Topics in The Software’s Life Cycle 56
5.1 Silver bullets 56
5.2 Project checklist 57
5.3 Fork 59
5.4 Technical debt 59
5.5 Timeboxing 60
5.6 Reusing 60
5.7 Tracking bugs 60
5.8 Bug repairs 61
5.9 Maintenance 61
5.10 Being simple and quite 63
5.11 Validation ＆ verification 63
Chapter 6 Requirements Risks 64
6.1 Important questions to ask before development starts 64
6.2 Risk analysis 67
6.2.1 The danger of not having a software requirements specification 67
6.2.2 The danger of having too many requirements 68
6.2.3 The danger of not talking to customers 69
6.2.4 The danger of preconceived ideas 69
6.2.5 The danger of ambiguity 71
6.3 Gathering requirements 71
6.3.1 Use cases 72
6.3.2 Requirements workshops 73
6.3.3 Prototyping 73
6.3.4 Brainstorming 73
6.4 Prioritizing requirements 75
6.5 Inspecting requirements 76
6.6 Structure of SRS 76
6.7 Common problems in SRS 77
6.8 Change of requirements 78
Chapter 7 Development 82
7.1 Schedule and budget 82
7.2 Processes 83
7.2.1 Waterfall 84
7.2.2 Extreme programming 84
7.2.3 Adopting a balanced approach 85
7.2.4 Iterative and evolutionary development 85
7.2.5 DevOps: combining development and operations together 85
7.2.6 Adhering to a process 86
7.3 Project efforts 87
7.4 Cost 87
7.5 Design 88
7.5.1 Design decisions 89
7.5.2 Why is design difficult? 89
7.5.3 Abstraction 90
7.5.4 Simplicity 91
7.5.5 Modularity 91
7.5.6 Handling undesired events 91
7.5.7 Formal inspections 92
7.6 Naming variables 92
7.7 Coding style 94
7.8 Comments and code 94
7.9 Programming languages 94
7.10 Pace 95
7.11 Versions 96
7.11.1 Concise and informative commit messages 96
7.11.2 Atomic commits and small pull requests 97
7.12 Test-first, test-early and test-last 97
7.13 Testing 99
7.13.1 Spell and grammar checking 101
7.13.2 Static code analysis 101
7.13.3 Unit testing 101
7.13.4 Usability testing 102
7.13.5 Regression testing 102
7.13.6 Code inspection and walkthrough 105
7.13.7 Test coverage 105
7.13.8 Test case density 106
7.13.9 Test case quality 106
7.13.10 Enough testing? 107
7.13.11 The trade-off between automated testing and manual testing 107
7.13.12 Test data generators 107
7.13.13 Testing in a small software company 108
7.14 Releasing 108
7.15 Continuous improvement 109
7.15.1 Continuous integration/continuous delivery 109
7.15.2 Continuous deployment with Docker 110
Chapter 8 Rules, Laws, and Plots 114
8.1 10 Years Rule 114
8.2 Eyeballs and bugs 115
8.3 Fish in the pond 115
8.4 Brooks’ Law 115
8.5 Goodhart’s Law 116
8.6 Cost to fix an error in different phases 116
8.7 Development cost versus maintenance cost 116
8.8 External quality versus internal quality 117
Chapter 9 Maintenance Stories 118
9.1 English Pal 118
9.2 Child Physical Examination Booking Application 119
9.3 The GNU Nano Editor 120
9.4 Lab Report Repository 124
9.4.1 Logging in with student number 125
9.4.2 Regression 126
9.4.3 Batch entering student numbers 132
9.4.4 Showing assignments that missed the deadline 135
9.4.5 A group member’s name appears more than once in group information 136
9.4.6 Definition of done 137
9.4.7. Other improvement areas for the Lab Report Repository web application 138
Chapter 10 References 140
Chapter 11 Appendices 143
11.1 Original requirements for Lab Report Repository 143
11.2 Correspondence between Ashly and the author on maintaining LRR 145
11.3 Software engineers, software writers, and entrepreneurs 148
11.4 End-to-end testing 148
11.5 Kanboard installation guide 151
11.6 Research questions 152