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

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

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

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

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.

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

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.

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

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”

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.

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

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

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

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

15 AREAS OF SLOWING DOWN

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.

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

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

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

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

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

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

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?

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.

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.

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

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.

HELL DEPENDENCY OF MICROSERVICES

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.

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

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

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

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

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

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

Hexagons in practice

domain infra

No content

No content

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

No content

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

No content

a SEARCH

a c SEARCH PAYMENT

c a SEARCH PAYMENT ACCOUNT

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?

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

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

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

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

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.

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

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

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

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.

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

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

No content

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.

@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.