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)
   

   View Slide

2. View Slide

3. Workflow
   

   View Slide

4. Workflow
   A repeatable pattern of activities that may be
   considered a view or representation of real work
   

   View Slide

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.
   

   View Slide

6. 1. Build a specification
   (a.k.a) figure out what you’re going to do
   

   View Slide

7. View Slide

8. View Slide

9. View Slide

10. View Slide

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.
    

    View Slide

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.
    

    View Slide

13. 2. Start with ?
    

    View Slide

14. View Slide

15. View Slide

16. View Slide

17. View Slide

18. View Slide

19. Tests
    • Types of test
    
    • Unit tests
    
    • Isolated tests
    
    • Quick feedback
    
    • Add/update functionality
    
    • Bug fixes
    
    • Refactoring
    

    View Slide

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
    

    View Slide

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
    

    View Slide

22. Deliverables
    1. Domain layer with tests.
    

    View Slide

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.
    

    View Slide

24. 3. Build other components
    Sequentially or in parallel (preferably)
    

    View Slide

25. Screen
    Business
    Logic
    View
    Renderer
    Effect
    Handler
    Subsystems UI Glue
    Login
    19th
    6th
    SecureStorage
    AuthApi
    

    View Slide

26. Screen
    Business
    Logic
    View
    Renderer
    Effect
    Handler
    Subsystems UI Glue
    Login
    19th
    6th
    A. Varies across architectures
    B. Should be parallelizable
    SecureStorage
    AuthApi
    

    View Slide

27. Screen
    Business
    Logic
    View
    Renderer
    Effect
    Handler
    Subsystems UI Glue
    Login
    19th
    6th
    A. Deadline
    B. Screen name
    SecureStorage
    AuthApi
    

    View Slide

28. Screen
    Business
    Logic
    View
    Renderer
    Effect
    Handler
    Subsystems UI Glue
    Login
    19th
    6th
    A. Checkmark
    B. Deadline (Optional)
    C. Person
    SecureStorage
    AuthApi
    

    View Slide

29. View Slide

30. Deliverables
    1. All other components + tests, ready to be glued.
    

    View Slide

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.
    

    View Slide

32. 4. Write Glue Code
    Wire ’em together
    

    View Slide

33. Screen
    Business
    Logic
    View
    Renderer
    Effect
    Handler
    Subsystems UI Glue
    Login
    19th
    6th
    SecureStorage
    AuthApi
    

    View Slide

34. Screen
    Business
    Logic
    View
    Renderer
    Effect
    Handler
    Subsystems UI Glue
    Login
    19th
    6th
    SecureStorage
    AuthApi
    

    View Slide

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.
    

    View Slide

36. Screen
    Business
    Logic
    View
    Renderer
    Effect
    Handler
    Subsystems UI Glue
    Login
    19th
    6th
    SecureStorage
    AuthApi
    

    View Slide

37. View Slide

38. Deliverables
    1. A feature that can be played around with on a device or an emulator.
    

    View Slide

39. 5. Test with local stubs
    So that you’re not surprised!
    

    View Slide

40. interface AuthenticationApi {
    fun login(request: LoginRequest): Single
    }
    

    View Slide

41. interface AuthenticationApi {
    fun login(request: LoginRequest): Single
    }
    class StubAuthenticationApi : AuthenticationApi {
    override fun login(request: LoginRequest): Single {
    return Single.just(LoginResponse("some-random-token"))
    }
    }
    class StubAuthenticationApi : AuthenticationApi {
    override fun login(request: LoginRequest): Single {
    return Single.error(RuntimeException("KABOOM!!"))
    }
    }
    

    View Slide

42. Deliverables
    1. The same binary that you built in the previous step (plus, fixes if any for
    edge cases).
    

    View Slide

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.
    

    View Slide

44. 6. Integrate and test manually
    Again! To avoid surprises!
    

    View Slide

45. Deliverables
    1. A build that’s ready for QA to look into.
    

    View Slide

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
    

    View Slide

47. –Vinay Shenoy
    “This is A workflow, not THE workflow.”
    

    View Slide

48. Predictability
    The fact of always behaving or occurring in the
    way expected
    

    View Slide

49. High-Performance
    Designed to achieve high speeds and high
    standards
    

    View Slide

50. 1. Master the IDE
    

    View Slide

51. Key Promoter
    

    View Slide

52. Explore the IDE
    

    View Slide

53. Productivity Features
    • Use multi-cursors
    
    • Refactoring tools
    
    • Live templates
    
    • Postfix completion
    

    View Slide

54. Staying Informed
    • Keep the gutter visible (icons / color)
    
    • Line numbers
    
    • Logcat colour for log levels
    
    • Rainbow Brackets (Plugin)
    

    View Slide

55. View Slide

56. 2. Practice
    

    View Slide

57. View Slide

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.
    

    View Slide

59. 3. Architecture
    

    View Slide

60. Data Flow
    

    View Slide

61. State Management
    

    View Slide

62. View Slide

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.
    

    View Slide

64. 4. Tooling
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

67. end;
    @ragunathjawahar
    Twitter / Medium / GitHub
    

    View Slide