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.

Dafc4723e9a1c067796c0fec6f509774?s=128

Lemi Orhan Ergin

November 02, 2019
Tweet

Transcript

  1. SLOW DOWN TO GO FASTER IN SOFTWARE DEVELOPMENT lemi orhan

    ergin, co-founder of craftbase
  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
  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
  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
  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.
  6. rushing makes us neither faster, nor more productive rushing increases

    stress, distracts focus and destroys productivity. we need creativity, effectiveness, and focus instead.
  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.
  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
  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”
  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.
  11. LEGACY SOFTWARE works perfectly validated by unit tests already deployed

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

    to prod but it has a bad smell do you get it?
  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
  14. SLOWING DOWN the only way of going faster with sustainable

    pace is
  15. 15 AREAS OF SLOWING DOWN

  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.
  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
  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
  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)
  20. One driver, many navigators Switch the keyboard regularly At least

    half a day in every week Mob Programming
  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
  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
  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?
  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.
  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.
  26. Build and document the system design of your product If

    you cannot visualize the big picture, you cannot manage, extend, improve and execute.
  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.
  28. HELL DEPENDENCY OF MICROSERVICES

  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.
  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
  31. Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

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

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

    ui domain
  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
  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
  36. Hexagons in practice

  37. domain infra

  38. None
  39. None
  40. Sebastian Daschner from his talk about “Design principles for the

    effective developer” at Devoxx Ukraine 2019
  41. None
  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
  43. None
  44. a SEARCH

  45. a c SEARCH PAYMENT

  46. c a SEARCH PAYMENT ACCOUNT

  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?
  48. Weekly Releases STEP-1 Multiple Releases in a Day STEP-3 Daily

    Releases STEP-2
  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
  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
  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
  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.
  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
  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
  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
  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.
  57. If you want to go fast, go African Proverb If

    you want to go far go alone together
  58. If you want to go fast, go Software Development Proverb

    If you want to go far go with pair with mob
  59. None
  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.
  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.