Bertrand Bougon

Bertrand Bougon

Developer, eXtreme Programmer, TDD lover, DDD practitioner

NewCrafts 2023

8 minute read

I have assisted to NewCrafts conference 2023, and I wanted to share the notes I have taken during this 2 amazing days.

NewCrafts 2023

Emily Bache - Hands-on techniques for getting legacy code under control

Working on legacy, bad / poor testing code, technical debt is part of our work.

To make the sufficient changes effective in order to make this code maintainable and testable, peel and slice strategy is a useful technique.

Quote from Emily:

  • Technical debt is deficiencies in internal qualities that make it harder than it would ideally be to modify and extend.
  • Everyone has an interest at reducing the technical debt.

Peel and Slice strategy:

Peel strategy: take away the untestable code. “Peel” technique is useful when the logic to be tested is in the between hard-to-test code (i.e. code with side effects). It consists of extracting the logic into a separate function, and then test that function instead of the initial one

Slice strategy: replace the hard to test code with a stub or a fake

Advantages/disadvantages:

Advantages:

  • Don’t break the signature of the called method
  • Extract a testable code
  • Make untestable code testable
  • Identifying side effects (and push them on the boundaries)

Disadvantages:

  • Event if we used refactoring tools, we didn’t have tests covering steps
  • Expose a method with a package visibility for testing purpose
  • Can introduce bugs during the slice and peel because the code is not covered in tests
  • The number of parameters can increase drastically and the combinatory of the test can explode

Tips and tools:

Use the tools you have in hands instead of redoing things. Use the refactoring tools from your IDE, look for tools that exists and that are adapted in your context (in such exercice, use approval testing)

Some tools for approval testing:

Sophie Kuster - The impostor’s guide to tooting You Own Horn

Impostor syndrome, also known as impostor phenomenon or impostorism, is a psychological occurrence in which people doubt their skills, talents, or accomplishments and have a persistent internalized fear of being exposed as frauds(Wikipedia).

I feel like an impostor about having impostor syndrome.

The following tips are Band-Aids, quick tips to help yourself about your feelings and start the process of acceptance:

  • Fake it till you make it, after all, we all pretend. Faking it is a start for self-confidence.
  • Make self advocacy a team sport

At the end, you need to face the monster whispering in your mind. You have to know this enemy and externalize impostor thoughts.

But you Live with the monster, and he will always be there. The monster speaking into your head keeps you away from being humiliated. You can make friend with the monster, or at least peace. Harness the power of good enough, internalize accomplishments (list all the achievements you’ve done, in your professional life or personal life), embrace failure

Impostor Syndrome is a fear response!

Books:

Adam Tornhill - Code red: The business impact of code quality

What is a technical debt?

  • code that is more expensive to maintain than to create it
  • 23 to 42% of developer time is spent on dealing with technical debt

It goes way beyond financial waste, unseen vulnerabilities have a disaster effect on finance at some point.

The laws of software evolution:

  1. continuing change (a system must be continually adapted, or it becomes progressively less satisfactory) => quick reward
  2. Increasing complexity (as a system evolves, its complexity increases unless work is done to maintain or reduce it) => slow feedback

Technical debt is a shortcut to slow death.

Why short-term gains win over long-term maintainability: Hyperbolic discounting (we might make choice today that in the future we may regret).

Fighting hyperbolic discounting: visualize technical debt and code complexity (code health) makes it obvious that you deal with a codebase that will be unmaintainable if you don’t accept to do the necessary effort to keep every change simple.

The result of the study, Research to quantify the impact of code quality spotted that:

  • implementing a feature is twice as fast on a healthy code quality than on a low code quality
  • A feature can take up to 9 times longer
  • contains 15 times more defect than healthy code

Rethinking Productivity in Software Engineering

The most frequent causes of unhappiness:

  1. stuck in problem-solving
  2. time pressure
  3. work with bad code

Code quality constraints a business:

  • Share the same awareness to all stakeholders (devs, product, management)

    Fight hyperbolic discounting

  • Discussing future risks primes you for starting to address them

Build a business case of improvements

  • Refactoring and larger improvements can come with a business expectation

Commit frequency can help to prioritize what part of the code needs to be refactored.

All tech debt does not need to be fixed!

Laurent Bossavit - Dear Feedback, you’re Loopy!

Fear: my job is to perfect you! (Fantasy experienced as reality). It can interfere with many things in life, feedback is one of them.

Feedback is more difficult when power is involved.

It needs safety and consent.

  • When somebody delivers some feedback to you (it gives information from the person giving feedback to you). If it comes from a third person, you cannot have clarification.
  • manipulation <> reject <> feedback

Agile has been turned as a tool for pressure rather than a tool to socialize organisation.

Feedback can change the relationship, hopefully in a good way but sometime in a bad way.

System thinking: what matters are not the things but the relationship between things.

miro

  • Prefer feedback loop over feedback. A feedback is not a one way discussion, it is the opportunity to open a discussion.
  • take care of your relationship
  • system thinking is a great tool to work on relationship

Books

Clare Sudbery - Compassionate Refactoring

when refactoring, you have to be compassionate with yourself and with other people.

Maaret Pyhäjärvi - Let’s Do a Thing and Call It Foo

Maaret is a tester but what does it mean to be a tester?

  • Manual testing? No, she never did a manual test in her entire career
  • Automated tester? No, writing some automated test from acceptance criteria or whatever is not her job

Let’s say my work is foo, because if you don’t know a thing that you want to create, call it foo. I hate the word foo, but I used it many times. The key is we don’t really understand what we are doing, we should name the thing after we understood what they are doing.

Testing is about breaking illusions, my job is to find something others may have missed. In my area of work, manual testing should not exist. The joy rely on the feedback given by the team when they fix what you’ve found.

We are accountable for:

  • Intent / Implementation
  • Domain for the Layman
  • Domain for the expert
  • Reference implementation
  • People filtering

Let’s try this with roman numbers.

Intent / Implementation

Developer intent. It might not do what you want to.

IV and IIII are both acceptable roman numbers, their intent are different, IIII is used in domain for luxury clocks and clock towers.

Same for V, IIIII is used in tomb marking

These are matters of business decisions. Ask the PO, why are we doing this? What is the domain? Can you show examples?

A simple Kata like roman number needs an intent and domain knowledge / decision. Decision matters!

I care for the perfect information (not the perfect implementation).

Business rules. You think you know them but you don’t.

Domain

  • Be the resident expert. Ask around
  • Rules, more rules
  • find better experts
  • disagreeing with boundaries
  • oracles
  • find better oracles
  • no user would do what users would do

Environment

  • Dependencies
  • Interruptions. Both…

People are not pure functions; they have all sorts of interesting side effects (Engineering Management for the rest of us, Sarah Granser)

Finally, we can call foo Contemporary Exploratory Testing, because that’s what my job does.

A majority of bugs of the production failures (77%) can be reproduced by a unit test.

The team needs information. Testers have to focus on that.

Seb Rose - Improving Software Quality with Contract Testing and Pact

Consumer challenges:

  • component not ready
  • lack of documentation
  • new version available

Provider challenges:

  • don’t know the audience
  • don’t want to manage multiple test instances

If you cannot deploy a component independently, this is not a component (it is a componented monolith).

Clients use a provider solution with the existing defects. If you update your service as a provider, fixing a bug, maybe you broke a client use case.

Contract testing is about sharing the use cases of our clients in order to run them on our service to be sure, as a provider, we didn’t break their usage. Pact is a tool where clients share the expected outcome from the provider solution, the provider may use these expected outcome with pact and have a direct feedback of any breaking change with their new deployment.

Andrea Magnorsky - Knowledge sharing is Systems building

Workshop

Why is it hard to share knowledge

  • You ship what is in your programmers brains

At beginning, it is easy as it is tiny, but it will grow (more code, more complexity). We focus on how do we solve this problem, we love those problem. When it comes to people, it turns to ghost.

Added difficulty:

  • Changing teams (new comers => new ideas, leavers => loose knowledge)
  • Coordination between teams (<> goal alignment, long asynchronous talk / feedback)
  • Conflicting long term plans (negotiation on conflicting things)
  • Role depends on information variance

A way to share knowledge: Bytesize Architecture Session

Bytesize Architecture Sessions[T] is a workshop format

  • simple
  • 45 minutes

You can’t reach the consensus, you only can approach a consensus.

[Architecture Modernization]https://www.manning.com/books/architecture-modernization

Teams need to understand the system they are working in.

Jessica Kerr - Going Deep on Gamification

Sorry, no notes as I gave my laptop to Jessica who faced technical issues.

Cyrille Martraire - Beyond Craft - Revisiting Our Relationship with Software Craft

Deequ Great expectations

Updated:

You May Also Enjoy

How to be proud of an experimentation

9 minute read

Sometime, even if it’s not that easy, trying hard to resolve something you are not sure about, at the end you can be proud about what you’ve done and God it...