Gleeson Working with Coders

A Guide to Software Development for the Perplexed Non-Techie
1. Auflage 2017
ISBN: 978-1-4842-2701-5
Verlag: APRESS
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 227 Seiten, eBook

Get introduced to the fascinating world inhabited by the professional software developer. Aimed at a non-technical audience, this book aims to de-obfuscate the jargon, explain the various activities that coders undertake, and analyze the specific pressures, priorities, and preoccupations that developers are prone to. In each case it offers pragmatic advice on how to use this knowledge to make effective business decisions and work productively with software teams.

Software projects are, all too often, utter nightmares for everyone involved. Depending on which study you read, between 60 and 90 percent of all software projects are completed late, run over budget, or deliver an inferior quality end product. This blight affects everyone from large organizations trying to roll out business change to tiny startups desperately trying to launch their MVP before the money runs out. While there has been much attention devoted to understanding these failings, leading to the development of entire management methodologies aimed at reducing the failure rate,  such new processes have had, at best, limited success in delivering better results. 

Based on a decade spent exploring the world of software, Patrick Gleeson argues that the underlying reason for the high failure rate of software projects is that software development, being a deeply arcane and idiosyncratic process, tends to be thoroughly and disastrously misunderstood by managers and leaders. So long as the people tasked with making decisions about software projects are unaware of these idiosyncrasies and their ramifications, software projects will be delivered late, software products will be unfit for purpose, and relations between software developers and their non-technical colleagues will be strained. Even the most potent modern management tools are ineffective when wielded blindly.

To anyone who employs, contracts, manages, or works with software developers, Working with Coders: A Guide to Software Development for the Perplexed Non-Techie delivers the understanding necessary to reduce friction and inefficiencies at the intersection between software development teams and their non-technical colleagues.

What You'll Learn

• Discover why software projects are so commonly delivered late and with an abysmal end product
  
• Examine why the relationship between coders and their non-technical colleagues is often strained
  
• Understand how the software development process works and how to support it effectively
  
• Decipher and use the jargon of software development
  
• Keep a team of coders happy and improve the odds of successful software project delivery
  

Who This Book Is For

Anyone who employs, contracts, or manages software developers—such as tech startup CEOs, project managers, and clients of digital agencies—and wishes the relationship were easier and more productive. The secondary readership is software developers who want to find ways of working more effectively as part of a team.

Zielgruppe

Professional/practitioner

Autoren/Hrsg.

Gleeson, Patrick

Inhaltsverzeichnis

1;Contents;6
2;About the Author;7
3;Acknowledgments;8
4;Introduction;9
5;Chapter 1: Introductions;11
5.1;Who you are;12
5.1.1;The Project Manager;12
5.1.2;The CEO;13
5.1.3;The Client;13
5.1.4;Sound familiar?;14
5.2;Who I am;14
5.3;What this book is;15
5.4;What this book is not;17
5.4.1;This is not a book about young white male nerds;17
5.4.2;This is not a book about how to code;19
5.4.3;This is not an attack on non-technical people;20
6;Chapter 2: Why Writing Software Is Nothing Like Building a House;21
6.1;The sad truth about software projects;22
6.1.1;Crunchy numbers;25
6.2;The Imagination Problem;27
6.2.1;Birthday wishes;28
6.2.2;Technical specifications, human processes;30
6.2.3;Starting from the wrong place;33
6.2.4;A counterproductive mitigation;34
6.3;The Estimation Problem;36
6.3.1;A known issue;37
6.3.2;The uninteresting;40
6.3.3;The unknown;43
6.3.4;Refusing to play the game;46
6.3.5;Estimates are graphs, not points;48
6.3.6;Empiricism;49
6.4;The Arithmetic Problem;51
6.4.1;The case of Pheidippides and the singing gorillagram;52
6.4.2;Brooks’s Law;54
6.5;In summary;54
7;Chapter 3: (Fr)Agile;55
7.1;A brief introduction to Agile;55
7.1.1;SCRUM;57
7.1.2;Other methodologies;60
7.1.3;The advantages of Agile;61
7.2;Small sprints and big decisions;63
7.2.1;Keeping it minimal;65
7.3;Stakeholder buy-in;67
7.3.1;“I don’t need to check in every week—just send me a report”;67
7.3.2;“But I already know what I want”;68
7.3.3;“But this new thing needs to get done right now”;69
7.3.4;“But I need those estimates now”;70
7.3.5;Buy-in is fine, but embraces are better;71
7.4;Embedded designers and the two-way conversation;72
7.4.1;Syncing;72
7.4.2;Two steps forward, three steps back;73
7.4.3;Integration;74
7.4.4;Agile vs Lean;76
7.4.5;Cleaning up;76
7.4.6;Agile AND Lean;78
7.5;When not to use Agile;79
7.5.1;Long cycle times;79
7.5.2;The communicable and the knowable;80
7.5.3;Two types of trust;81
7.6;In summary;82
8;Chapter 4: What Do They Do All Day?;83
8.1;What to build;84
8.1.1;Spec it before you build it;84
8.1.2;Yes, you do need to spec it;85
8.1.3;UX details matter;86
8.1.4;A functional specification;88
8.1.5;3.2.7: Key Stats Summary Screen;91
8.1.6;Telling tales;92
8.1.7;A User Story is not a specification;94
8.1.8;It’s a given;95
8.1.9;3.2.7: Key Stats Summary Screen;95
8.1.10;Handing over;97
8.2;Code;98
8.2.1;Ones and zeroes;99
8.2.2;Computer guts;102
8.2.3;Software development is an abstract art;104
8.2.4;Objectified;109
8.2.5;Coding is modeling (but not the glamorous type);113
8.3;Done;114
8.3.1;Source control;115
8.3.2;A second pair of eyes;116
8.3.3;Deployment;119
8.4;In summary;121
9;Chapter 5: The Big Green Check Mark;122
9.1;The hard way;123
9.1.1;Does it do what it says it does?;124
9.1.2;Does it do what it doesn’t say it does?;124
9.1.3;Does it do what it said it did?;126
9.1.4;Coping with failure;126
9.1.5;Just accept it;129
9.1.6;Where there’s smoke;130
9.2;The other hard way;131
9.2.1;Internal examinations;133
9.2.2;Test drives;138
9.3;Invisible quality;140
9.3.1;Indebted;141
9.3.2;Prevention;142
9.3.3;Cure;144
9.4;In summary;147
10;Chapter 6: Taking the “Arg” out of Jargon;148
10.1;Internet;149
10.2;Data;155
10.3;Security;159
10.4;Coding;163
10.5;In summary;168
11;Chapter 7: So You Need to Hire a Coder;169
11.1;Do you actually need a coder?;170
11.1.1;Build vs. buy;170
11.1.2;Hired guns;172
11.1.3;Foreign shores;174
11.2;How to look for a coder;175
11.3;How to interview a coder;178
11.3.1;Technically challenging;179
11.3.2;Being human;181
11.4;How to get a coder to say yes;183
11.5;In summary;184
12;Chapter 8: Programmer Preoccupations;185
12.1;The forum phenomenon;186
12.2;The Hype Cycle;189
12.2.1;The thrill of the new;189
12.2.2;Tech death;191
12.2.3;Teething problems;192
12.3;Coder wars;193
12.4;Beauty in code;195
12.5;In summary;198
13;Chapter 9: Keeping Coders Happy;199
13.1;A quiet room and a powerful computer;200
13.1.1;Keeping shtum;201
13.1.2;Unleashed;202
13.2;Odd hours;202
13.2.1;Flexibility;202
13.2.2;Feeling the burn;203
13.3;Old and new;205
13.3.1;Being supportive;205
13.3.2;Legacies;207
13.4;Open sourcing;209
13.5;Continuing to learn;211
13.6;In summary;212
14;Chapter 10: When It All Goes Wrong;213
14.1;When your team hate each other;214
14.2;When you’re horribly behind schedule;217
14.3;When your product just isn’t very good;219
14.4;Wrapping up;223
15;Index;224

Über Autor(innen)

Patrick Gleeson has been a coder and a manager of coders for the past 10 years. He has worked in a variety of organizations, from bespoke software consultancies to multinational corporations to tiny start-ups, and is currently CTO of Think Smart, a company that provides tools to help young people make better career choices. He holds a degree from the University of Cambridge in Philosophy and Classics, and another one from the London Academy of Music and Dramatic Art in Technical Theatre. He also sidelines as a composer for film and theater, and once spent a year building animatronic puppets as part of a robot circus, including a mechanical octopus that played the xylophone.