All you need is tools

Developers architect apps, write software, develop new features, and attend conferences like WWDC to learn and bring the new exciting features into their apps. To do so, they use Apple’s official tools like Xcode, and open source projects like CocoaPods or Fastlane. Those are powerful tools but designed and optimized to meet the needs of any sort of project: large, small, written in Swift, but also in Objective-C, for solo developers, and for large teams.

When projects start getting far off the standards for which the tools are optimized, the tools and services can turn into a source of issues. Those usually hold the teams back from being productive and delivering a high-quality final product.

In this talk, I talk about why investing effort into developing your own tools is crucial to move on steadily with motivated and productive developers. Furthermore, I'll give attendees some tips to know when is the right time to do such investment, and go through some real examples of impactful tools that my team has developed to bring best practices and conventions across the whole organization.

Transcript

1. Pedro Piñera Buendía | @pepibumur All you need is tools
2. • Based in Berlin but originally from Spain. • Build tools for mobile developers at Shopify (iOS & Android). • Love doing open source work like Tuist (tuist.io). • github.com/pepibumur • twitter.com/pepibumur About me
3. • Why you should invest in tools. • How to design, develop, and release great tools. • Examples of tools that we’ve developed at Shopify. What will I talk about?
4. Developers need tools to create apps.
6. Tools can make you productive and bring you focus.
7. Tools can prevent errors or make them more obvious.
8. Tools can automate manual work.
9. Tools define a shared language, facilitating cross- project work.
10. Tools are usually designed to target a group of users and their needs.
11. Xcode Optimized for small & medium sized apps. Large apps come with complexity, high compilation times, and no flexibility to change the build process.
12. Fastlane Optimized for teams which barely can invest time into tooling. Used extensively results in a lot of duplication and untested automation code.
13. Bazel Optimized for large projects with high compilation times. Used in small projects it introduces unnecessary overhead.
14. There aren’t good or bad tools; 
 there are tools more suitable to your needs than others.
15. When a tool doesn’t suit our needs, our natural response is to tweak it.
16. Compilation with Xcode is slow I’ve seen person X, who works for company Y, who published a tweet talking about the flag Z, which should speed up compilation.
17. There isn’t a Fastlane lane to do X I’ve seen someone who published this piece of Ruby code on Stackoverflow that we can wrap into a lane and problem solved.
18. Manageable code Shared code Consistency Reliability (tests) Deterministic Readable errors Reproducible environments Unreadable code Duplication Inconsistencies Untested code Flakiness Puzzling errors Non-reproducible environments Well-designed tools Tweaked tools
19. High-quality tools Developers’ productivity & motivation High-quality products
20. Tips 
 How can I create high-quality tools?
21. Talk to your users about their problems. 1
22. Talk to your users
23. Add integration tests. Because the contract with the local environment is out of your control. 2
24. Integration tests
25. Add metrics. You can’t improve the tools if you don’t understand how developers use them. 3
27. Tools are software; test them and strive to keep the software well structured. 4
28. Tools should evolve with the project. Today’s tools and processes might not work in the future. 5
29. Prefer convention over configuration. 6
30. Convention Configuration
31. The standard output and error are limited resources. Don’t waste them! 7
33. Treat errors as first-class citizens. Try to understand them and make them actionable. 8
34. Not-handled error
35. Handled error
36. Tools are products. They need to be devised, designed, implemented, documented, released, supported, iterated… 9 %
37. Questions are opportunities to build tools. 10
38. Examples
39. - An iOS developer “I’m trying to set up my local environment to work with this project but I can’t figure out how.”
40. Dev tool %
41. - An iOS developer “I’d like to test out this PR but I’d spend 15 minutes compiling the app.”
42. Mobile tophat
43. Mobile tophat
44. - An iOS developer “Releasing apps is so frustrating; the last time it failed due to signing issues and this time the compilation fails.”
46. Easy to consult current and past releases.
47. Easy to create a hot- fix release. Suggestion of the next version number. Integrates with CI statuses.
48. Easy to see who is responsible for the release. Prevents uploading the app when the tests are failing. Easy to distribute to different channels.
49. - An iOS developer “Maintaining the Xcode projects became a burden; when I add new frameworks to the stack, I have to change many settings and build phases.”
51. Demo
52. • Investing in tooling pays off in the long term. • Tools are products; development is one step in the process. • They deserve the same love that is put into the product they are meant to be used with. • Don’t push tweaks beyond their limits. Takeaways
53. Thanks! Pedro Piñera Buendía
 @pepibumur - pedro.pinera@shopify.com Slides: https://bit.ly/31aGO7q