Save 37% off PRO during our Black Friday Sale! »

Building Predictable and High-Performance Workflows

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.

A8ee6ea52b89dfa1388b592a260c60a6?s=128

Ragunath Jawahar

March 30, 2019
Tweet

Transcript

  1. Building Predictable & High-Performance Workflows @ragunathjawahar • Obvious (formerly Uncommon

    Bangalore)
  2. None
  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
  7. None
  8. None
  9. None
  10. None
  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 ?

  14. None
  15. None
  16. None
  17. None
  18. None
  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
  29. None
  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
  37. None
  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)
  55. None
  56. 2. Practice

  57. None
  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

  62. None
  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