Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building Predictable and High-Performance Workf...

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.

Ragunath Jawahar

March 30, 2019
Tweet

More Decks by Ragunath Jawahar

Other Decks in Programming

Transcript

  1. 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.
  2. 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.
  3. 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.
  4. Tests • Types of test • Unit tests • Isolated

    tests • Quick feedback • Add/update functionality • Bug fixes • Refactoring
  5. 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
  6. 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
  7. 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.
  8. Screen Business Logic View Renderer Effect Handler Subsystems UI Glue

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

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

    Login 19th 6th A. Checkmark B. Deadline (Optional) C. Person SecureStorage AuthApi
  11. 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.
  12. Glue • DI container setup for the screen / feature.

    • View interface implementation for your Activity / Fragment / Custom View / View Controller. • Boiler plate for architecture infrastructure.
  13. 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!!")) } }
  14. Deliverables 1. The same binary that you built in the

    previous step (plus, fixes if any for edge cases).
  15. 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.
  16. 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
  17. Staying Informed • Keep the gutter visible (icons / color)

    • Line numbers • Logcat colour for log levels • Rainbow Brackets (Plugin)
  18. 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.
  19. 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.
  20. 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.
  21. 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