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
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
40. Sebastian Daschner from his talk about “Design principles for the effective developer” at Devoxx Ukraine 2019
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
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
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.