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

Slow Down To Go Faster In Software Development

Slow Down To Go Faster In Software Development

Software development has evolved so quickly throughout the years. New tools, methodologies, practices, even new disciplines and principles have been introduced. From single individuals to tens of inter-connected development teams, from co-located teams to fully-remote distributed teams, software development professionals have developed new ways of doing their professions to achieve one single target: Building successful products.

Regardless of the technologies we use and the structures we build, our biggest challenge remain still: Catching deadlines, building high-qualified software that lasts long and being in the market earlier than our competitors. Going fast without control could be the biggest enemy of software development. After working as Agile Practice Lead for years and touching hundreds of teams in my career, I now believe the only way to go fast is going slow efficiently.

Going slow could destroy your career, your product, even your company, but it is the only way to go faster to succeed. In this talk, you will learn:

* how to build a development culture that builds software faster than ever.
* the principles and techniques behind slowing down under control.
* the myths and fallacies of development practices and the realities behind.
* real life examples of establishing an environment for efficient continuous delivery.

By the end of the talk, you will be able to know how you can change the way you and your team should work to go faster than ever.

Lemi Orhan Ergin

November 02, 2019
Tweet

More Decks by Lemi Orhan Ergin

Other Decks in Programming

Transcript

  1. SLOW DOWN
    TO GO FASTER
    IN SOFTWARE DEVELOPMENT
    lemi orhan ergin, co-founder of craftbase

    View Slide

  2. LEMi ORHAN ERGiN
    co-founder, Craftbase
    founder, Software Craftsmanship Turkey
    alumni, Sony, eBay
    programming, since 2001 with love
    based, Istanbul, Turkey
    speakerdeck.com/lemiorhan
    @lemiorhan

    View Slide

  3. being fast is vital
    not only being first on the market is important, but also responding
    to customers by adding new features and eliminating bugs fast keep
    customer satisfaction high.
    in so!ware world

    View Slide

  4. Parkinson’s Law states that work expands to fill the time and
    resources assigned to it. We usually put pressure on ourselves by
    assigning virtual deadlines and that increases focus and productivity.
    we manufacture
    deadlines for ourselves

    View Slide

  5. but we all have a
    problem with speed
    we assume going faster, smarter and efficiently is related with
    giving deadlines for the targets and rushing to catch them.
    we think that we go faster by working more and with more people.
    therefore we either add new people or do overtime to gear up production.

    View Slide

  6. rushing makes us neither
    faster, nor more productive
    rushing increases stress, distracts focus and destroys productivity.
    we need creativity, effectiveness, and focus instead.

    View Slide

  7. so!ware development is
    damn hard & complex
    we cannot get rid of complexity. we have to live with it.
    the need for speed creates an unstable, unsustainable environment,
    makes us stressed, less focused and less productive. it just don’t work.

    View Slide

  8. incompetence is reality
    deadlines have direct dependency with the competency of
    people, efficiency of the processes and the quality of output.
    are imaginary
    team capacity
    velocity
    estimation
    deadline
    masterplan
    fixed hours
    time sheets

    View Slide

  9. Agile doesn’t cure INCOMPETENCE.
    You can coach teams to be more engaged and
    collaborative, but NO Agile framework, method,
    or mindset can save you from BLATANT FAILURE
    if your development team is INCOMPETENT in
    basic engineering practices.
    Technical excellence is a MUST!
    Mike Beedle
    @mikebeedle
    7:48 PM · Mar 21, 2018
    https://twitter.com/mikebeedle/status/976500772438409216
    Mike Beedle (died at March 23, 2018)
    Agile Manifesto co-creator
    proposed the term “agile” to manifesto co-creators
    introduced “Enterprise Scrum” and “Business Agility”

    View Slide

  10. we got legacy so!ware
    and inefficient processes
    the pressure of deadlines combining with incompetency leads to
    legacy so"ware, the dead-end for a working so"ware.
    at the end of the day
    with poorly wri#en code, you start an endless
    “Do-Panic-Redo” loop till your product dies.

    View Slide

  11. LEGACY
    SOFTWARE
    works perfectly
    validated by unit tests
    already deployed to prod
    but it has a bad smell
    do you get it?

    View Slide

  12. LEGACY
    SOFTWARE
    works perfectly
    validated by unit tests
    already deployed to prod
    but it has a bad smell
    do you get it?

    View Slide

  13. https://twitter.com/unclebobmartin/status/555013005751377920
    Robert C. Martin
    co-creator of agile manifesto and creator of software craftsmanship manifesto
    evangelist on professionalism, clean code and tdd
    if your so"ware is ge#ing harder and harder
    to develop, you are doing something wrong.
    Uncle Bob Martin
    @unclebobmartin
    4:46 PM · Jan 13, 2015

    View Slide

  14. SLOWING DOWN
    the only way of going faster with sustainable pace is

    View Slide

  15. 15 AREAS OF
    SLOWING
    DOWN

    View Slide

  16. developer
    developer
    Recruitment is too important
    to be left to recruiters
    Always interview developers with developers.
    Ask for fundamentals. Developers without
    fundamentals do not solve problems. They simply
    create new elegant problems.
    Never hire someone without seeing them coding
    and criticizing code with you.

    View Slide

  17. Hiring requires onboarding and adaptation phases.
    Huge hirings destroy the existing culture.
    Never hire more than 10% of employees at one time.
    Never allow
    the culture of new comers
    dominate the existing culture

    View Slide

  18. Never allow silos & heros
    to occur
    Treat having silos and heros as dysfunctions.
    Two cures we know so far:
    • Knowledge and experience sharing
    • Conversations and discussions

    View Slide

  19. Every week, at the same place and time
    one of your colleague shares something
    technical or non-technical
    something worth sharing
    Lunch & Learn (BBS)

    View Slide

  20. One driver, many navigators
    Switch the keyboard regularly
    At least half a day in every week
    Mob Programming

    View Slide

  21. If you have dependency to another team to
    complete your task…
    Your organization has problems with devops culture
    Your team has lack of cross-functionality
    You are working for a project, not a product
    Your platform has lack of proper design or architecture

    View Slide

  22. If you have dependency to another team to
    complete your task…
    Your organization has problems with devops culture
    Your team has lack of cross-functionality
    You are working for a project, not a product
    Your platform has lack of proper design or architecture

    View Slide

  23. expertise in programming languages
    Scrum, XP
    monoliths /microservices
    evolutionary architecture, emergent design
    hexagonal architecture / ports and adaptors
    branching mechanisms / trunk based development
    automated tests (unit, integration, functional, etc)
    pair & mob programming
    code review, team standards
    continuous integration
    design patterns & refactoring
    test driven development (tdd, bdd, atdd)
    expertise in frameworks
    project management
    consumer driver contract testing
    transaction management
    static code analysis
    event handling / messaging
    non-blocking io, data streaming
    monitoring & traceability
    resilient architecture
    asynchronous communication
    cache management
    rest / grpc api management
    Sufficient to build a successful product?

    View Slide

  24. Know your domain
    We need more domain experts than
    technology experts in sector.
    Only the ones who knows the domain
    well can create proper solutions that
    really solve a problem.

    View Slide

  25. Make developers on-call
    Usually developers work behind the walls without
    knowing the impact of their work.
    Let them break the walls and touch customers. Let
    them listen them. Let them feel empathy.

    View Slide

  26. Build and document
    the system design
    of your product
    If you cannot visualize the big picture,
    you cannot manage, extend, improve
    and execute.

    View Slide

  27. Start with monoliths
    If you have no experience with building
    microservices at production, it could be a
    nightmare if you jump into it. Microservices
    requires to have devops culture, agile
    mindset and a new paradigm for software
    development. So be pragmatic.

    View Slide

  28. HELL
    DEPENDENCY
    OF MICROSERVICES

    View Slide

  29. Focus on modularity
    If you cannot develop well-crafted monoliths,
    how can you be sure you can build well-
    crafted microservices?
    Make your architecture clean and modular by
    following related design patterns and
    principles. Make your monolith well-crafted
    first. Then if you need to scale, split it to
    microservices.

    View Slide

  30. https://twitter.com/martinfowler/status/606096712969633794
    Martin Fowler
    Author, speaker, and general loud mouth on Software Development.
    Works for ThoughtWorks.
    posted: the monolith-first strategy to
    building microservices (or not)
    Martin Fowler
    @martinfowler
    4:54 PM · Jun 3, 2015

    View Slide

  31. Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

    View Slide

  32. Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

    View Slide

  33. ports
    business
    adapters
    mysql
    adapter
    stripe
    adapter
    rest
    api
    web
    ui
    domain

    View Slide

  34. ports
    adapters
    domain
    3rd party apps
    command line
    soap calls
    admin gui
    batch jobs
    mobile apps
    other hexagons
    cache provider
    elastic search
    mail server
    database
    sms provider
    message queue
    other hexagons
    business
    mysql
    adapter
    stripe
    adapter
    rest
    api
    web
    ui

    View Slide

  35. ports
    adapters
    notification
    payment
    billing
    order
    basket
    restaurant
    scheduling
    caching
    search
    mail
    account
    messaging
    stripe
    adapter
    rest
    api
    mysql
    adapter
    web
    ui
    domain
    business

    View Slide

  36. Hexagons in practice

    View Slide

  37. domain
    infra

    View Slide

  38. View Slide

  39. View Slide

  40. Sebastian Daschner
    from his talk about “Design principles for the effective developer”
    at Devoxx Ukraine 2019

    View Slide

  41. View Slide

  42. ports
    adapters
    notification
    payment
    billing
    order
    basket
    restaurant
    scheduling
    caching
    search
    mail
    account
    messaging
    stripe
    adapter
    rest
    api
    mysql
    adapter
    web
    ui
    domain
    business

    View Slide

  43. View Slide

  44. a
    SEARCH

    View Slide

  45. a
    c
    SEARCH
    PAYMENT

    View Slide

  46. c
    a
    SEARCH
    PAYMENT
    ACCOUNT

    View Slide

  47. Release and deploy code to
    prod multiple times a day
    Trunk Based Development lets you release
    multiple times a day. But it is a long journey to
    complete.
    do you really need that?

    View Slide

  48. Weekly
    Releases
    STEP-1
    Multiple
    Releases
    in a Day
    STEP-3
    Daily
    Releases
    STEP-2

    View Slide

  49. Daily
    Releases
    STEP-2
    Multiple
    Releases
    in a Day
    STEP-3
    Using Git-Flow
    Everyone codes individually
    No/few tests, huge manual test cost
    CI server used for building packages
    Weekly releases at best
    Manual deployment to pre-prod
    Manual functionality testing
    Manual deployment to prod
    DoD: Developed & tested at local

    View Slide

  50. Multiple
    Releases
    in a Day
    STEP-3
    Master-Feature branching
    Active Pair programming
    Have a primitive test suite
    CI server runs tests for validation
    Daily releases at best
    Pull requests for code review
    Automatic deployment to pre-prod
    Manual functionality testing
    Manual deployment to prod
    DoD: Deployed to pre-prod
    Using Git-Flow
    Everyone codes individually
    No/few tests, huge manual test cost
    CI server used for building packages
    Weekly releases at best
    Manual deployment to pre-prod
    Manual functionality testing
    Manual deployment to prod
    DoD: Developed & tested at local

    View Slide

  51. No branches, just master
    Feature flags
    Active Mob programming
    Have a elegant test suite
    Multiple releases per day at best
    No pull requests
    Each commit is deployable
    On-demand env. at each merge
    Automatic deployment to pre-prod
    Automatic acceptance testing
    Manual deployment to prod
    DoD: Deployed to prod
    Master-Feature branching
    Active Pair programming
    Have a test suite
    CI server runs tests for validation
    Daily releases at best
    Pull requests for code review
    Automatic deployment to pre-prod
    Manual functionality testing
    Manual deployment to prod
    DoD: Deployed to pre-prod
    Using Git-Flow
    Everyone codes individually
    No/few tests, huge manual test cost
    CI server used for building packages
    Weekly releases at best
    Manual deployment to pre-prod
    Manual functionality testing
    Manual deployment to prod
    DoD: Developed & tested at local
    trunk based development

    View Slide

  52. Do not write tests to pass,
    write production code to
    make tests pass
    TDD has more refactoring than testing, more
    thinking than coding, more simplicity than
    elegancy. That's why it leads to better quality.

    View Slide

  53. Worried that TDD will slow down your
    programmers? Don't. They probably need
    slowing down.
    J. B. Rainsberger
    @jbrains
    7:23 PM · Feb 8, 2012
    https://twitter.com/jbrains/status/167297606698008576
    J.B. (Joe) Rainsberger
    got highest honor from agile community, the Gordon Pask Award in 2005
    teaches TDD via his "the World's Best Introduction to TDD” online course

    View Slide

  54. First I thought TDD was about testing, then
    that was about designing, now I'm convinced
    it's about thinking at sustainable pace
    Uberto Barbini
    @ramtop
    2:45 PM · Mar 12, 2017
    https://twitter.com/ramtop/status/840891605116735488
    Uberto Barbini
    JVM and Kotlin independent consultant
    public speaker, blogger, author

    View Slide

  55. Write tests at multi levels
    You have time for fixing bugs, but not writing tests
    Write integration, component, functional, load and security tests
    Have just enough tests
    Focus on testing behaviors, not implementation details
    Stop calculating code coverage
    Delete your brittle tests, rewrite tightly coupled code

    View Slide

  56. Build systems
    embracing failures
    It is useless to push for high availability
    for pod-level in microservice world. Every
    system will collapse, every microservice
    will stop and every request will drop from
    time to time.
    Focus on self-healing and resilience by
    adding retry mechanisms and creating
    anomaly detection systems, running real
    time and scheduled.

    View Slide

  57. If you want to go fast, go
    African Proverb
    If you want to go far
    go
    alone
    together

    View Slide

  58. If you want to go fast, go
    Software Development Proverb
    If you want to go far
    go
    with pair
    with mob

    View Slide

  59. View Slide

  60. Working software does not
    have to be well-crafted.
    Only good professionals can
    build well-crafted software.
    Only well-crafted software
    lets you build features faster
    than ever.

    View Slide

  61. @lemiorhan
    LEMi ORHAN ERGiN
    Working software does not
    have to be well-crafted.
    Only good professionals can
    build well-crafted software.
    Only well-crafted software
    lets you build features faster
    than ever.

    View Slide