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

Code Is Cheap, Show Me The Purpose

Code Is Cheap, Show Me The Purpose

Lemi Orhan Ergin

November 18, 2023
Tweet

More Decks by Lemi Orhan Ergin

Other Decks in Technology

Transcript

  1. why we cannot increase code quality and work in legacy

    ? why we write tests, do pair programming and collaborate ? why the features we created are not used as expected and thrown away ? why I cannot improve myself and do the same things over and over again ? ALWAYS LEGACY NO TESTS & SOLO WASTE FEATURES LOSING SKILLS
  2. the team is rushing to catch the deadline get-it-done mindset

    overemphasis on efford estimations primary goal is to complete all tasks no time for testing in development custom frameworks are created to narrow focus and understanding new teammates join to go faster technical dept is accepted
  3. individual speed and productivity are crucial no time for helping

    peers and working in pairs hard to onboard juniors to team critical tasks go to seniors micro management happens
  4. metrics are collected to manage productivity story points per person

    is calculated tons of metrics with no real meaning are collected, like team productivity, velocity, code coverage performance appriasals based on metrics destroys justice & team spirit
  5. plans should be obeyed scope is fixed we know customers

    will like it product owners as as analysts, no need to know the product internals feature prioritization is for catching the deadline poker planning for hours only few people touch and hear real customers
  6. lords of the house are the decision makers know-how is

    kept at seniors and architects, who form a separate team everyone has separate duty, has limited visibility on the big picture lack of skill development for others high turover rate with many outsources team mates
  7. all the problems you face are normal if what you

    build is a project it does not matter if everyone say you build “a prouct” what you build quacks like a duck, and walks like a duck, then it is a duck (a project) that is the bitter truth
  8. software product is not a software written for a customer

    by a team a green-field project with latest technologies used an output of a Scrum team running sprints something developed iteratively something you demo at the end of every sprint an output of the team using a board and tasks a product if it is been built as if it is a project
  9. building a project is like taking care of someone else’s

    child what you really care is getting the given tasks done and get paid for it
  10. you follow long term vision and a purpose learn from

    every failure aim is sustainable satisfaction & growth there is no end for growth and development look for continuous improvement seek for good people and processes building a product is like growing your own child
  11. Product KPIs Time https://medium.com/ctonun-el-defteri/startup-dinamikleri-ve-cto-rolleri-18af101649cc Hakan Erdoğan, Startup Dinamikleri ve CTO

    Rolleri EARLY STAGE SCALE STAGE LATE STAGE Main concern: Speed Quality Business Continuity Main Focus: Validation Growth Customer Satisfaction Customer Development Sustainability Customer Loyalty Developed: Product Projects MVP products start to die when it loses capability for innovation and adaptability SIGMOID CURVE OF BUSINESS
  12. Product KPIs Time SIGMOID CURVE OF BUSINESS SECOND CURVE THEORY

    AT RE-SCALE STAGE Main concern: Quality Main Focus: Growth Customer Satisfaction Developed: Product first curve second curve
  13. from building products LESSONS LEARNED 10 to show you how

    building a product is different than building a project
  14. estimations considered waste 1 efford/complexity/time estimations are never accurate due

    to high degree of uncertainty and variability, diverse perspectives, insufficient knowledge and unreliable assumptions care customer priorities, quality and purpose more
  15. seniority levels are toxic, get rid of them product success

    needs collective ownership and decision making, and collaboration of the whole team. expect craftsmanship and professionalism from everyone, and let everyone initiate leadership. 2 you don’t have time of bureaucratic bullsh*t!
  16. be an expert of your product & domain without full

    knowledge of the product, you are not a part of the solution, you are a part of the problem recently developed with latest technologies. 3 good products are built by “product” developers
  17. program in pairs and with team do together, practice together,

    learn together, improve together 4 slow down to go faster
  18. cultivate a quality-oriented collaborative neighbourhood pressure 5 hire like-minded, disciplined,

    motivated, disciplined talents, give them the purpose, principles and values and let them shape the culture quality is an output of principled & disciplined teams
  19. get the best feedback you ever get touch/support your customers

    directly know how customers feel, what they want, what they don’t like. developers not touching the users develop projects, not products 6
  20. use technologies you are good at 7 or select the

    ones you don’t know, but you can expertise fast how can you claim you can deliver quality when you are not good at the technologies used ? be pragmatic and wise
  21. always be ready to deploy to prod release changes early

    & frequently 8 invest in CI/CD pipeline from day one shorten feedback loops with efficient pipelines and make changes available to customers fast
  22. quality & productivity cannot be measured don’t fool yourself, stop

    measuring it when a measure becomes a target, it ceases to be a good measure - Goodhart’s Law 9
  23. focus on building something in a way that you feed

    proud forget about agile {placeholder} stuff 10
  24. 1 cultivate neighbourhood pressure be an expert of your product

    & domain program in pairs and with team touch/support your customers directly use technologies you are good at release changes early and frequently don’t fool yourself, stop measuring productivity 2 3 4 5 6 7 8 9 estimations considered waste seniority levels are toxic, get rid of them focus on building in a way that you feed proud 10 10 lessons learned from building a product
  25. One-Stop-Shop Payment Orchestration talent @ craftgate.io we are hiring! LEMİ

    ORHAN ERGİN co-founder, craftgate speakerdeck.com/lemiorhan