How to be more pragmatic around the choices we make

As developers we make choices every day such as what framework to use, what tools to use and what browsers to support. All these decisions have a huge impact on both our experience as developers and the users experience when using out sites. Unfortunately these two areas are not aligned so lets have a look at how we can be pragmatic as developers taking into account both our users and developers experiences.

Transcript

1. How to be more pragma&c around the choices we make Jonathan Fielding @jonthanfielding
2. A bit about me… • Engineering Manager at Beamly (WE ARE HIRING) • Author of ‘Beginning Responsive Design’ • Regular contributor to open source, including SimpleStateManager, Echo.js, FT’s Polyfill Service, Doccy among many projects • My twiKer username is a accidental mis-spelling and is now a username I use EVERYWHERE
3. ORen as developers we find ourselves making lots of decisions
4. These decisions can have a huge impact on our project
5. It can make a huge difference to our user experience
6. It can have a major impact on the ergonomics of developing our applicaUon
7. The problem is most of the informaUon out there is laced with bias
8. We oRen see developers saying X is beKer than Y
9. Pledging their allegiance to their framework of choice
10. and I myself am guilty of this
11. So today I want to look at how we make these decisions
12. and encourage you to have confidence in the decisions that you make
13. What makes choosing a technology so difficult?
14. There is a huge amount of choice
16. Each piece of technology tries to solve a set of problems that developers face
17. It's therefore important to choose the technology that is right for your project
18. There is an overwhelming amount of informaUon to wade through
19. and with so much choice we need to be pragmaUc in making our decision
20. especially since it is difficult to separate fact from opinion
21. Learning to be pragmaUc
22. Let's start with a definiUon of pragmaUc
24. To a developer this means to make choices that fit within the constraints of our project
25. What are the constraints?
26. Knowledge
27. We first need to consider the knowledge we already have
28. And then we need to understand limits to what we can quickly pick up
29. We also need to understand what outside knowledge is available to us
30. Time
31. We are likely constrained by a deadline
32. This also impacts the Ume in which we can spend researching technology choices
33. Technology
34. The user's browser might constrain the features that we can use
35. The user's device might add performance constraints
36. Constraints impact the choices that you make as a web developer
37. and when being pragmaUc you need to make a decision that sits within these constraints
38. How biases can affect our pragmaUsm
39. Successful developers are those who are able to evaluate all potenUal opUons and choose the one that is best for the situaUon
40. However, good developers oRen fall vicUm to bad decisions
41. The most dangerous are our unconscious biases
42. And unless we are acUvely avoiding them then they can affect our decision making
43. We therefore need to acknowledge our biases
44. Confirma(on Bias
46. This can manifest itself in both how we search for informaUon and how we interpret it
47. To overcome confirma&on bias you need to seek ways to challenge what you think you see
48. Anchoring Bias
49. https://www.towergateinsurance.co.uk/liability-insurance/cognitive-biases
50. During normal decision making, we tend to weigh a specific piece of informaUon more heavily than other factors
51. To overcome anchoring bias you need to look more into the other technologies
52. Gamblers Fallacy
53. https://vivifychangecatalyst.wordpress.com/2017/05/27/random-walk-gamblers-fallacy-and-gamblers-ruin/
54. If we have had a problem using a technology before we might assume that our 2nd or 3rd Ume using it might go beKer
55. To overcome gamblers fallacy you need to understand why you might have failed at using a technology in the past
56. The Availability Heuris(c
57. https://www.towergateinsurance.co.uk/liability-insurance/cognitive-biases
58. If a technology is featured regularly on a subreddit we regularly visit, when it comes to making a decision we're more likely to recall informaUon on it which will bias our decision
59. To avoid this bias you need to ensure you are looking across a selecUon of technologies
60. External Biases
61. We also oRen encounter other people's biases when carrying out our research
62. In order to separate fact from opinion, we need to know what signs to look for
63. Watch for buzzwords
64. Look at how the writer talks about other frameworks or technologies
65. See if you could rewrite the arUcle, using the same informaUon, to tell a completely different story
66. “49% of developers agree that React improves their workflow”
67. “51% of developers agree that React does not improve their workflow”
68. Making a decision
69. Clarify your project Define a evaluation criteria Evaluate your success Implement Research each option Make the decision
70. Clarify your project
71. The first thing that we need to clarify is what are the user requirements
72. There are two different kinds of requirements
73. Func&onal Requirements
74. Non-Func&onal Requirements
75. These requirements will vary based upon what the user is aKempUng to achieve
76. A visitor to a website will have different requirements to the content editor who manages the content
77. To understand both types of requirements you need to ask quesUons
78. Who is your user?
79. What are they trying to achieve?
80. How is your site being accessed?
81. Taking the answers from each of our sets of users we can define a set of requirements
82. Aside from our user requirements we also need to clarify other details of the project
83. Who will be working on the project?
84. How much Ume do you have to complete the project?
85. Do you have to integrate with any third parUes?
86. Define a evalua(on criteria
87. Earlier we looked at the different kind of biases that can impact your project
88. A way to prevent bias is to idenUfy a clear evaluaUon criteria
89. What func(onality do we need from the technology?
90. Our funcUonality criteria should address all the func&onal and non- func&onal requirements
91. Will this technology work on the devices I have to support?
92. Does this technology support the needs of my users?
93. What does the technology offer to developers to improve usability?
94. Does the technology provide good documentaUon?
95. Does it work around any bugs in the web plaiorm?
96. How mature is the technology?
97. How old is the technology?
98. Are there many other developers using this technology?
99. How is the technology maintained?
100. How long will it take to implement using this technology?
101. Is the technology familiar to you or your team?
102. It is important to include in your criteria details around whether you or your team has had experience using the technology
103. Having iden(fied evalua(on criteria you should then put together a table lis(ng them all
104. How mature is the technology? Does the it have comprehensive documentation Does it meet my performance requireements Does it allow me to build accessible interfaces …
105. Apply weighUngs to your evaluaUon criteria
106. Weighting How mature is the technology? 20 Does the it have comprehensive documentation 100 Does it meet my performance requireements 20 Does it allow me to build accessible interfaces 100 … …
107. Research each op(on against the evalua(on criteria
108. The first step in researching what technology to use is to shortlist those you want to evaluate
109. First ask your colleagues and other stakeholders what technologies they want to include in the evaluaUon
110. Then you will want to use your favourite search engine to find others
111. Having shortlisted your technologies you now need to start researching each against the evaluaUon criteria
112. Evalua(ng the user requirements criteria
113. Look at open source components built on top of the technology
114. Look at the other websites that use the technology
115. Evalua(ng Maturity
116. The easiest way to determine the age of the technology is to look at when the iniUal commit was made
119. We can then see how acUve the community is by looking at issues and pull-requests
121. To determine how many companies are using the technology we can look at hiring trends
122. Hacker News Hiring Trends https://www.hntrends.com
123. Evalua(ng developer usability
124. Look at how well the technology is documented
125. One soluUon for comparing technologies is to build the same applicaUon in each one
126. Doing this ourselves is Ume consuming
127. and we might not even end up with soluUons that suit the framework
128. This is where we can look at example web apps built by the web community
129. The first of these is todomvc.com
133. We can then use these examples to see how code is structured for a parUcular framework
136. We can also do some benchmarking using the chrome devtools
144. Our second site for looking at implementaUons is Hacker News PWA hGps:/ /hnpwa.com/
145. It features different implementaUons for each of the frameworks so you can see different approaches
147. The final is the RealWorld example applicaUon hGps:/ /github.com/gothinkster/ realworld
148. It provides specificaUons for both the frontend and the backend
149. Focusing on building a full end to end applicaUon
150. All three of these tools help us to evaluate the framework we are looking at
151. Enabling us to discover the facts we need ourselves without the influence of biases
152. Make the decision
153. Rule out the riskiest opUons
154. Discuss with other developers in your team
155. Agree on what you want to use
156. Implement
157. Build your project using your chosen technology
158. Make a note of any problems you face which you can then reflect on later
159. Evaluate the success
160. Look at what went well
161. IdenUfy areas that you are unhappy with
162. Highlight any technical debt accrued
163. Summary
164. Approach choosing technologies you use in your projects with an open mind
165. Make decisions based on the type of project
166. Consider your users func&onal and non- func&onal requirements
167. Alongside the ergonomics you want from a technology
168. I hope you go away feeling confident in making these decisions
169. A special thanks goes out to Charlie Fielding along with the folks at Beamly for being the guinea pigs for this talk
170. Thank you, any ques(ons?