Building Predictable and High-Performance Workflows

Fragments 2019
https://hasgeek.com/fragments/2019/proposals/building-predictable-and-high-performance-workflow-gkcdjYRGfeUTcSH4L5Cx3T

Software development itself is a practice that is filled with entropy. Even though there are factors in software development that are beyond our control, there are quite a few parameters that can be controlled and tuned. One of the ways to maximize predictability in software projects is to reduce the number of unknowns. Most teams start with an architecture that sets expectations to a degree. How can we push this even further? What if we can build a degree of predictability on how software is built by individuals? What if we could extrapolate the same ideas to a team and across several teams?

This talk focuses on how various architectures (imperative and functional) influence individual and team throughput during development and maintenance. We’ll acknowledge how software development is a very creative profession but can also withdraw inspiring ideas from efficient systems like turn-key businesses and production lines that can help build software faster and better. We’ll focus on how the choice of architecture and tooling affect various phases of development. Once we gain an understanding of the architecture, we’ll create and tune a workflow by sequencing activities, establishing processes and building custom tooling around it.

Transcript

1. Building Predictable & High-Performance Workflows @ragunathjawahar • Obvious (formerly Uncommon Bangalore)
3. Workflow
4. Workflow A repeatable pattern of activities that may be considered a view or representation of real work
5. Soft Boiled Eggs 1. Get an egg at room temperature. 2. Add vinegar and salt to water. 3. Boil the water with egg for 8 minutes. 4. Dunk the egg in cold water for 3 minutes. 5. De-shell and serve.
6. 1. Build a specification (a.k.a) figure out what you’re going to do
11. Deliverables 1. A very clear understanding of what the product team wants. • State diagram (or) • TODO list / JIRA tickets / Trello cards / Others 2. All screens (some could be missing, but notify the design team about it). 3. JSON specification produced collaboratively with the backend team.
12. Take aways 1. Human interactions are one the longest feedback loops. 2. Don’t build something that you are not going to ship. 3. Minimise rework.
13. 2. Start with ?
19. Tests • Types of test • Unit tests • Isolated tests • Quick feedback • Add/update functionality • Bug fixes • Refactoring
20. Test-Driven Development • Spend more time in the problem space • Missed something? Figure out sooner than later • Design feedback • In minutes / hours / days vs. months / years • Pace
21. Roman Numerals Problem Time (minutes) 24 25.5 27 28.5 30 First Second Third No TDD TDD http://www.codemanship.co.uk/parlezuml/blog/?postid=1021
22. Deliverables 1. Domain layer with tests.
23. Take aways 1. Aim for quick feedback cycles in every stage of development. 2. Reduce the amount of interference that creeps into your work from other teams.
24. 3. Build other components Sequentially or in parallel (preferably)
25. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue Login 19th 6th SecureStorage AuthApi
26. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue Login 19th 6th A. Varies across architectures B. Should be parallelizable SecureStorage AuthApi
27. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue Login 19th 6th A. Deadline B. Screen name SecureStorage AuthApi
28. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue Login 19th 6th A. Checkmark B. Deadline (Optional) C. Person SecureStorage AuthApi
30. Deliverables 1. All other components + tests, ready to be glued.
31. Take aways 1. Architecture is a corner stone in building workflows and maintainable applications. 2. DI (not referring to Dagger) helps in building loosely coupled applications and facilitates parallel development. 3. Critical information should be readily available.
32. 4. Write Glue Code Wire ’em together
33. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue Login 19th 6th SecureStorage AuthApi
34. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue Login 19th 6th SecureStorage AuthApi
35. Glue • DI container setup for the screen / feature. • View interface implementation for your Activity / Fragment / Custom View / View Controller. • Boiler plate for architecture infrastructure.
36. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue Login 19th 6th SecureStorage AuthApi
38. Deliverables 1. A feature that can be played around with on a device or an emulator.
39. 5. Test with local stubs So that you’re not surprised!
40. interface AuthenticationApi { fun login(request: LoginRequest): Single<LoginResponse> }
41. interface AuthenticationApi { fun login(request: LoginRequest): Single<LoginResponse> } class StubAuthenticationApi : AuthenticationApi { override fun login(request: LoginRequest): Single<LoginResponse> { return Single.just(LoginResponse("some-random-token")) } } class StubAuthenticationApi : AuthenticationApi { override fun login(request: LoginRequest): Single<LoginResponse> { return Single.error(RuntimeException("KABOOM!!")) } }
42. Deliverables 1. The same binary that you built in the previous step (plus, fixes if any for edge cases).
43. Take Away 1. Fail fast, edge cases are sources are constant surprise during development. Don’t wait for QA to figure out the obvious ones.
44. 6. Integrate and test manually Again! To avoid surprises!
45. Deliverables 1. A build that’s ready for QA to look into.
46. Workflow 1. Build a specification 2. Start with the domain 3. Build other components 4. Write glue code 5. Test with local stubs 6. Integrate and test manually
47. –Vinay Shenoy “This is A workflow, not THE workflow.”
48. Predictability The fact of always behaving or occurring in the way expected
49. High-Performance Designed to achieve high speeds and high standards
50. 1. Master the IDE
51. Key Promoter
52. Explore the IDE
53. Productivity Features • Use multi-cursors • Refactoring tools • Live templates • Postfix completion
54. Staying Informed • Keep the gutter visible (icons / color) • Line numbers • Logcat colour for log levels • Rainbow Brackets (Plugin)
56. 2. Practice
58. Why? 1. Evaluate architectures. • Presents various constraints in Android. 2. Simple problems so that you can focus more on workflows. 3. Helps build muscle-memory.
59. 3. Architecture
60. Data Flow
61. State Management
63. Why? 1. Functional, hence easier to deal with asynchrony. 2. Unidirectional data flow, easier to test and isolate faults. 3. Isolation between logic and side-effects. 4. Printing the state object gives us all the information we need.
64. 4. Tooling
65. Best Practices 1. Tools and libraries should provide quick feedback.
 Earlier in the development cycle, the better. 2. Pick tools that seamlessly blend into your workflow. 3. Minimise the amount of external tools. 4. Reliance of debugger / tools that help debugging efficiently means there is scope for improvement. 5. Restrict additional tooling for specific purposes. 6. Consider using a Git GUI client.
66. External Links • https://plugins.jetbrains.com/plugin/4455-key-promoter
 (Don’t get the Key Promoter X Plugin) • https://github.com/ragunathjawahar/bench-press • https://github.com/spotify/mobius • https://github.com/spotify/mobius.swift • https://www.gitkraken.com
67. end; @ragunathjawahar Twitter / Medium / GitHub