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.

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