Thoughts On Books: The Design of Everyday Things

Posted by claudiolassala in User Experience on February 16, 2023

This isn’t a book “review”; this is quick summary of what I got out of reading The Design of Every Things, by Don Normal. This content comes from what I’ve shared as a lightning talk for my fellow Improvers. I’ll keep referring to this book as DOET, for short.

Do I recommend this book?

Yes, I do. However, I’d recommend reading Kathy Sierra’s Badass: Making Users Awesome first; it helped me appreciate DOET more.

I have similar thoughts when comparing the canonical GoF book on Design Patterns to Head First Design Patterns; the former is a very dry read, although very comprehensive, whereas the latter is much easier to read (not coincidentally, Kathy is also involved in that one, and I really like that style of book).

DOET was originally published in 1988; the edition I’ve read is the “expanded and revised” one published in 2013. Even though some of the revised content may not resonate with younger readers, it did resonate with me.

Does it relate to software development?

As its title implies, the book is not about software development. However, it does mention some examples in software. But the way I see it is that it brings a shared vocabulary to design-related terms, much like design patterns do in software development.

Besides myself, two of my teammates participated in the book club, and we’ve been able to leverage the concepts learned in the book as we work in our project. Some concepts include:

  • Affordances
  • Signifiers
  • Constraints
  • Mapping
  • Feedback
  • Conceptual model

Here’s how I understand some of those concepts…

Affordances

I think of it as a door to a building. That door is how I relate to the building; it’s how I can get in.

Signifiers

For whatever odd reason, this is the image that comes to mind when I think of signifiers:

Constraints

For constraints, this is what comes to mind:

If you don’t get the reference, here’s a great 51-second video.

Contextual Model

As a hobbyist musician, I really appreciate how recording software models the experience we get in the real world.

For example, instead of showing me data entry forms to indicate how I want to my recorded guitar to sound, I get something that looks and behaves similarly to its counterpart in the real world.

As I move the microphone around on the screen, looking for a better positioning in front of the speakers, I hear the sound that reflects that setting, very similar to the experience in a real world studio.

To learn about those concepts, consider checking out Denny’s Improving Talk, Improving Software Design with Everyday Things, built on the lightning talk he shared with us at the end of the book club:

Human-Centered Design

Two points that resonated with me in the Human-Centered Design (HCD) section of the book:

  • Solving the right problem, doing so in a way that meets human needs and capabilities
  • Find the right problem, then find the right solution

I’ve recently shared my thoughts on approaching behavior-driven development without focusing on system behavior.

Most developers tend to immediately jump into their favorite technical solution, neglecting the needs and context of the humans who should benefit from it.

In the book, Norman says “I never solve the problem I am asked to solve“. I agree, and have been working hard for years trying to always separate the wants from the needs.

One of the examples in the book mentions a person walking in a store wanting to buy a drill bit. They don’t want a drill bit, they want a hole? Or do they? Their book library is growing, so they want new shelves. Would they consider trying ebooks instead? Do they want more books for their need to grow their knowledge through reading?

What have I been pondering?

There is a section later in the book that talks about humans and machines. Here are some thoughts that came from that…

Humans have been coaching other humans for a long time now. Even people at the top of their game have coaches.

human-human

The book good me thinking about the aspect of:

  • Humans coaching Machines, and
  • Machines coaching Humans

human-machine

week human + machine + better process
superior to
strong human + machine + inferior process

Trying to think about that in the context of an accounting software:

novice accountant + computer + software with a built-in coaching process
superior to

seasoned accountant + computer + bad software

This next passage also got me thinking:

“Once technology can do our arithmetic, can remember for us, and can tell us how to behave, then we have no need to learn these things.”

Woah. Hold on. Technology telling us how to behave? So, what if we approach behavior-driven development with a spin of “the valuable desired behavior we’d like to coach humans into“? Food for thought.

I’ve enjoyed watching “The Future Of” Series on Netflix. The episodes on Gaming and Headphones are my favorites.

Best advice in the book

I’ve marked several passages in the book. This is my favorite one, which I come back to fairly often:

  • Do not blame people when they fail to use your products properly.
  • Take people’s difficulties as signifiers of where the product can be improved.
  • Eliminate all error messages. Instead, provide help and guidance.
  • Make it possible to correct problems directly from help and guidance messages. Allow people to continue with their task: Don’t impede progress. Never make people start over.
  • Assume that what people have done is partially correct. If it is inappropriate, provide the guidance that allows them to correct the problem and be on their way.

For more…

If you crave for more, look up Don Norman’s videos on YouTube; there are some great ones out there.

And there’s also this one by yours truly!

Leave a comment

Optimize code for reading, not debugging

Posted by claudiolassala in Software Development on February 8, 2023

I see a lot of code that includes variables not used for anything:

The variable inside of that method does not add anything to improve the understanding of the code. That’s normally done to make debugging easier, when setting a breakpoint and hovering over the variable to inspect it:

That way, the developer can set a breakpoint, and hover over the variable to inspect it.

Instead of doing that, I’d rather have that method written like this:

When I need to debug that method and inspect what it returns, I use the shortcut to *introduce a variable*, do my debugging, and then either undo the change or hit the shortcut to *inline the variable* (most IDEs support such refactoring. Even if the one I’m using doesn’t, creating a variable named *x* or *temp* should take no time).

Some IDEs, such as Rider, even show a method’s return in the debugger without the need for a variable, as seen below:

Summing up:

  • Optimize the code for reading
  • Get familiar with your IDE’s debugging capabilities
  • Change the code to facilitate debugging when needed
  • Change the code back for optimized reading before committing it

Leave a comment

BDD: What if we do NOT focus on ‘System’ behavior?

Posted by claudiolassala in testing on February 2, 2023

This is a way many people and literature talk about Behavior-Driven Development (BDD): “it encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.” (wikipedia)

Focus on the application‘s behavior leads to user stories that start like this:

As a system…

Do we write code for the system?
Are we serving the system?
Is the system a stakeholder?

Continuing the story…

I want to…

Oh, so the system tells us what it wants? Are we already there?

Most software developers have a strong tendency to jump too quickly into problem-solving from a technical perspective, failing to see the problems the humans need solving.

Say we’re using state-of-the-art technology, implemented with the most amazing code, on the most advanced platforms, using valuable resources, such as time, attention, and money; it it worth it if humans’ lives aren’t any better?

Many times, the problem that needs solving is a process problem. Many times, it’s a people problem. Often times, social and/or cultural problems also get in the mix. Here’s an example of the latter:

A socio-cultural problem

In the mid 2000s, I met a group of developers in Redmond who had just come back from Sao Paulo, Brazil.

They had been working on a pilot project to improve the quality of public transportation, implementing a tracking system for the buses, so people could know with more accuracy when their next ride would show up.

The system was working great, except for this one bus that kept “disappearing” from the system for at least 30 minutes everyday. Puzzled, they developers were looking at the data, code, and everything in between.

The cause of the problem?

The bus driver found out how the system worked and figured out he could use its sim card in his own phone to make long distance calls to his family, who lived in the north part of the country. That was a time when long distance calls were still very expensive.

Most local developers would have caught that possibility that the foreign ones didn’t consider. The system was behaving according to spec. But the humans…

Maybe the problem that needs solving is dealing with some people’s natural behavior that may put them far from a bigger goal.

Maybe we’re trying to develop a solution that will acknowledge people’s natural behavior and make sure the desired outcome is achieved.

Or maybe the solution can help change people’s behavior gradually.

Here’s an example. In 2017, I started riding sport bikes (motorcycles, that is) at race tracks. It didn’t take much to realize that it can be an expensive sport. Doing my research and asking other riders how much they spend in their riding season, some would say “I don’t even wanna know!” Asking how often they ride, some would answer “whenever money permits“.

Well, I do want to know; if I know and understand where the money goes, I can identify ways to optimize my expenses and get to ride more!

Here’s one of the user stories I wrote at the time to capture that need (which I implemented in www.BeyondTheTrack.net and have been using all these years):

Estimating Costs

In order to plan out a track day calendar within my budget
As a rider
I want to indicate estimated costs for each track day

Scenarios for the story looked something like this:

Given track days I plan on attending
When I enter their estimated costs
Then I can see the budget I will need for my riding season

By facilitating a behavior of setting proper budget for goals that are important to me, my life is better. My behavior. Not the system’s behavior.

How did that work out for me in that specific case?

Comparing my Year #1 in track day riding to Year #6, the number of days I rode went up by 146%, while the money I’ve spent on it went down by 78%. Value up, cost down. Win-win in my book. The chart below shows 2017 through 2022.

The closer we get to the bits and bytes, yes, specs will tend to describe what we expect from the system. But that’s NOT where I believe we should start from.

In the great books Specification by Example and Writing Great Specifications, the authors are very specific at sticking to the definition of BDD as Dan North meant it.

In this post, I’ve put my own spin on it, as this is how I’ve practiced it over the years.

In his talk about “Leadership vs Management: What it means to make a difference”, Seth Godin talks about how people think Beethoven’s 5th Symphony should sound: the way the maestro wrote it, or the way made popular by Arturo Toscanini? Interesting watch.

,

Leave a comment

Read one book or many at a time?

Posted by claudiolassala in books on January 26, 2023

Should we read one book or many at a time? I’ll tell you what my experience has been, hoping that it may help you experiment and see what works best for you.

As an English as a second language teenager, I started to read one fiction book after another for many years. That is, I’d read daily, and as soon I finished one book, I’d start the next one.

Fast forward to 2016, when I shared how I was catching up with my book reading. At that time, I said “I have the bad habit of starting to read several books and then taking a long time to finish (I just finished a book that I started to read 3 years ago!)”

Why did I refer to that habit as bad? Because it takes a long time to finish? So what?

I’ve since realized that I can finish reading a book within a timeframe if needed; when I’m in a book club, or taking a course that has deadlines for the reading assignments. For all other books, I just take my time. No need to hurry.

I picked up Tribe of Mentors in 2018, and finished it in 2022! At some point I’ll skim over it again, reflecting on highlights and notes I wrote for the book.

Be always reading

But back to reading many books at a time. I keep doing that. It’s a habit. Not a bad one.

Mark Manson brings up that up as one of his tips on how to read faster: read more than one book at a time.

For the record: I don’t necessarily want to read faster. I want to be always reading.

I try to choose books that are very different from each other; e.g., a technical book and soft skills book.

Sometimes I do end up starting books that turn out to have some overlap. That’s ok; I take note of that, often exploring differences between the different authors’ perspectives, or where they overlap.

What I’m reading at the moment

As I write this post, these are the books I’m actively (daily) reading at the moment:

These are the ones I read a few pages every week:

And this is one I read a few pages every month (I started it in 2017. No rush.):

What, when, how

I’ve been somewhat specific about what time of the day I read each book, and even which format (printed, ebook, audiobook).

The “morning” books are usually the ones I’m reading as part of a book club and I want to take more notes and reflect more on what I read, so I can have better conversations with the groups. I favor printed copies for these.

The “evening” ones are easy-reads that won’t get my mind too engaged with, otherwise, I’m not letting my mind rest while I sleep.

When I’m reading technical books, I favor reading those in the morning, so to stretch my brain, getting it active for the day. Again, I don’t want to feed the mind with complicated stuff right before going to bed; I used to do that, but not anymore.

I have been marking up the book with highlighters and writing notes directly on the pages and on stickies. When I finish the book, I go through it again, processing my notes, connecting them to other thoughts, which helps me wrap up books that take me a while to get through.

A conversation with multiple people

Here’s another way I’ve been thinking about this practice of reading multiple books at a time.

Say we walk into a party, strike conversation with someone, and 15 minutes later realize we couldn’t quite connect. Should we stick talking with that person through the end of the party? Maybe we should thank the person for the chat and politely check out.

Or maybe we did connect with the person and can tell we could easily spend hours chatting, but, we also notice that there are a few more people we’d like to connect with at that party. How about we exchange contact information, write down a few words to remember the context of the conversation, and then go chat with the other people?

We can approach books as conversations with their authors. Start the conversation, and if we’re having a good time, keep it going (or write some thoughts down and come back to it later).

But if it’s dragging and we feel it’s going nowhere, put… it… down!

We do NOT have to finish every book we start.

Sometimes I do feel like giving up on a book, but if it was highly recommended, I may stick with it a little longer, asking myself why I’m not enjoying it: is it the author’s tone, their analogies with which I can’t connect, too many points I heavily disagree with?

Whatever the case, I may find out I am the problem, and can think of ways to change my perspective in how I’m approaching my reading of such book.

So be always talking to many people. Be always reading.

4 Comments

Favorite Quotes in 2022

Posted by claudiolassala in lifestyle on January 19, 2023

Here are some of my favorite quotes read in 2022. In no particular order.

If opportunity doesn’t knock, build a door.
-Milton Berle

If you want to know your past look into your present conditions.
If you want to know your future look into your present actions.
-Chinese proverb

One who makes no mistakes makes nothing al all.
-Giacomo Casanova

No matter how bad or slow things go, you’re still way ahead of everyone who isn’t even trying.
-Tony Robbins

Your level of success will seldom exceed your level of personal development.
-Jim Rohn

When you create a difference in someone’s life, you not only impact their life, you impact everyone influenced by them throughout their entire lifetime.
No act is ever too small. One by one, this is how to make an ocean rise.
-Danielle Doby

Busy is a decision. We do the things we want to do, period. If we say we are too busy, it is just shorthand for the thing being “not important enough” or “not a priority.” Busy is not a badge.
You don’t find the time to make things, you make the time to do things.
-Debbie Millman

To what are you committed? What cause, what mission, what purpose?
What are you doing?
And more important, why are you doing it?
How does what you do every day reflect, in some way, the values you claim to care about?
-Ryan Holiday

Whether or not something is deemed a “failure” is dependent on when performance is measured.

I signed the book deal for Atomic Habits in November 2015 and it was published in October 2018. If you were to measure the performance of the book at any point during those three years, the project would have been deemed a failure. In January 2016? It was incomplete. A failure. In August 2017? Still unfinished. A failure. In February 2018? Again, a failure.

But after October 2018, it looked like a success. Same project. Different time when the outcome was measured.

This idea applies in many areas of life. You’re not failing. You’re just in the middle of succeeding.

-James Clear

In your actions, don’t procrastinate.
In your conversations, don’t confuse.
In your thoughts, don’t wander.
In your soul, don’t be passive aggressive.
In your life, don’t be all about business.
-Marcus Aurelius

No matter the lesson, you can teach it only by instilling a sense of pride, not shame, in the pupil.
-Harvey Mackay

Teaching is successful only as it causes people to think for themselves. What the teacher thinks matters little; what he makes the child think matters much.
-Alice Moore Hubbard

The best teachers are those who show you where to look, but don’t tell you what to see.
-Alexandra K. Trenfor

A mentor is not someone who walks ahead of us to show us how they did it.
A mentor walks alongside us to show us what we can do.
-Simon Sinek

Leadership: the capacity to identify a useful goal and enable its achievement.
Leadership emerges at the convergence of passion and responsibility.
-Harrison Owen

Great leaders know that people respond much more favorably to appreciation than to criticism. Appreciation inspires a person to excel, so as to receive more appreciation. Criticism tears people down, and people who don’t feel worthwhile don’t feel they can do a good job.

Leadership can be a daunting task. The use of criticism is an indication of a leader who lacks the resources to truly lead.

A leader’s job is the careful balancing of inspiration and direction.

-Will Bowen

For anyone who is considering growing old, I remind you that although physical abilities diminish with age, many mental capacities continue to improve, especially those dependent upon an expert accumulation of experience, deep reflection, and enhanced knowledge.

-Don Norman

Forgiveness is accepting the apology you will never receive.

-Shawne Duperon

If you don’t like something change it. If you can’t change it, change your attitude. Don’t complain.
-Maya Angelou

Leave a comment

Favorite Books I’ve Read in 2022

Posted by claudiolassala in books on January 13, 2023

Here are my favorites books read in 2022, in no particular order.

A Complaint Free World

In 2022, Improving has started a company-wide initiative called Come Together to “bring Improvers closer, no matter the distance.” Each month had a theme; for instance, January was wellbeing), and April was spirituality. For the latter, one Improver decided to extend the experience by running a book club, and the book chosen was Will Bowen’s A Complaint Free World. That book had been on my radar for a while, so I was glad to join the club.

The book has made me rethink some things:

  • Criticism and sarcasm? Both are a form of complaint.
  • Venting out frustrations? Not a great thing to do.
  • Yelling at an automated voice system? Not great, either, bud.

I took lots of notes and will likely condense some of them into a blog post. For now, here’s one of my favorite quotes on the book:

The squeaky wheel may get the grease. But if it squeaks too much, it ends up getting replaced.

The Untethered Soul

As we wrapped up the book club on A Complaint Free World, the group enjoyed it so much we decided we wanted to run another club on a similar group. After tossing some ideas around, we’ve landed on Michael A. Singer’s The Untethered Soul.

Easy read. I finished it quickly. We’re taking it easy with the book club, having the meetings without rushing it.

I’m glad we’ve picked up this book after the previous one, as it helped me look at similar ideas through different perspectives.

Chapter 12, Taking down the walls, is my absolute favorite. I could see that chapter turned into a movie. Or at least that’s how effective the author was at making me visualize what his words describe.

I wish I could draw that visualization. Since I can’t, I’ll drop an image here to remind me of it.

Atomic Habits

I started reading James Clear’s blog posts a few years before Atomic Habits was published. Some of his posts on identity building and related topics resonated with me, I followed some of his tips, and it made a difference. I read the book as soon as it came out, and it was a great refresher for the content I had already consumed. I either gifted or recommended the book to many people, and a good number of them came back to say they loved it.

Then, a group of Improvers showed interest in reading the book. What do we do then? Book club!

This was one of my favorite book clubs. We had a nicely-sized group, with folks joining from many of our offices.

It was great to hear about the habits different people were trying to either stop or start, their challenges, and also see some us getting teaming up as accountability partners.

Going through the book again while discussing it with such an engaged group of people was absolutely great.

And as it has become a tradition: we’ve wrapped up the club with many of us giving lightning talks to share our main takeaways, offered to another group of Improvers who were interested in hearing it.

Telling you, Improvers are a different breed. It’s part of our culture.

How to Live

How to Live was one of my favorite books in 2021:

“It has been only 2 months or so since I’ve read the book, and I’m planning on reading it again very soon“

And I did. I started on January 1st.

The 2nd time through was even better. I highlighted different passages, wrote down new notes on old passages, pondered more.

I’ll drop here two of my favorite passages.

On Learning

Teaching and learning are telepathy.
We can connect across oceans and centuries.
Words written by someone long ago and far away can penetrate your mind.
Share what you learn so it can be received by others, even when you are long gone.

On Making Memories

To enjoy your past is to live twice.
Nostalgia is memories minus the pain.
Turn your experiences into stories.

Last year I’ve also run into this great interview with Derek, in which at some point he talks about How to Live. I enjoyed listening because he helped me visualize some points I had missed when I read the book.

Anything You Want

Another re-read. Another one by Derek Sivers. I got an email letting me know the 3rd edition of Anything You Want – 40 lessons for a new kind of entrepreneur was out. I remember I enjoyed reading the 1st edition several years ago, so I figured it was a good time to revisit it. Also, I love Derek’s writing style and approach to book publishing, so I support him and hope he keeps putting out great content.

This book is a very quick read, filled with great gems. Here’s a couple of my favorites:

Starting with no money is an advantage. You don’t need money to start helping people.

And this one:

Your business plan is moot. You don’t know what people really want until you start doing it.

How to Write One Song

Up until I’ve read this book, I don’t think the following words had ever come out of my mouth: “I’m a songwriter”, despite having written many songs.

An Improver mentioned this book to me and I decided to check it out. As I read through it, I thought “hey, I’ve been doing most of those things for years!” So there, I am a songwriter!

Reading the book and trying out some of the techniques was a fun. A few lyrics for my most recent song, “From a Distance”, came out of that.

Since many Improvers ask me about my songwriting process, I created and taught a 3-hour class last year to teach them, focusing on writing lyrics, with some of the activities borrowed from this book. That was a ton of fun! One of the attendees took on the challenge and wrote his own lyrics for “From a Distance“, and we’ll be co-creating a Part 2 for that class, to share with others the lessons we both learned: him writing his first lyrics, and me getting to see my own creation interpreted and heard through a different perspective.

How to be Perfect

I got a little bit obsessed about the TV Series The Good Place. To this date, I watched its 4 seasons 3 times!

A comedy show that talks about philosophy? Does that work? Well, that one worked for me. And its series finale is my favorite one to date.

When I heard that the show’s creator, Michael Schur, was publishing a book to talk what he learned about philosophy and how he used it in the show, I knew I had to read it. I did, and enjoyed it.

My favorite part about the book is the author’s take on happiness and flourishing:

I prefer “flourishing,” because that feels like a bigger deal than “happiness.” We’re talking about the ultimate objective for humans here, and a flourishing person sounds like she’s more fulfilled, complete, and impressive than a “happy” person. There are many times when I’m happy, but I don’t feel like I’m flourishing, really.

Here’s Michael Schur’s “How Ethics Can Help You Make Better Decisions” TED Talk, where he goes over what triggered him to look into philosophy and eventually creating a TV show about it. Fascinating how we can turn our experiences around and make great things out of it.

Specification by Example

This book have been on my radar for a long time. I recommend it to anybody interested in Behavior-Driven Development, Given-When-Then (aka, Gherkin), and related practices.

The Design of Everyday Things

The book Badass: Making Users Awesome was among my favorites both in 2020 and 2021. Lessons learned from the book and applied to my work even inspired me to create a new “UX for Devs” type of talk (here’s a link to a recent presentation).

That book had also recommended several other books, and I decided to pick one of them next: The Design of Everyday Things. And guess what we did at Improving? Yup, book club!

Great attendance and great mix: half of the attendees were developers (including two devs from my own team), and the other half were UX designers. This mix was perfect for different perspectives and experiences to be shared. Having some of my teammates participate was also excellent, as we got to practice lessons learned together, building a common vocabulary, and sharing with the rest of our team.

I took a ton of notes on this one and keep going back to them to further refine my thoughts on what I learned.

Denny Kruep, one of my teammates who participated in the book club, will be presenting lessons learned from his perspective: Improving Software Design with Everyday Things. This is a free virtual talk happening January 18th, at 12pm CST. Click here to register and know more.

The Inner Game of Tennis

This is a great book, not just for those who play tennis; its lessons are valuable to anybody who wants to learn anything, and also to those who enjoy teaching others.

I’ve been playing tennis once a week for a couple of years now, as well as riding my motorcycle at the track almost every weekend. I’m applying lessons I’ve learned from this book to both sports and seeing good results. It’s also making me rethink how I normally teach and coach others, not just in sports, but on anything, really.

The Subtle Art of Not Giving a F*ck

I’d guess a lot of people do and a lot people don’t pick up this book because of its title. I’m not generally offended by language used like that, so I had to pick up this book after getting a good number of recommendations for it.

In nutshell: this book is about deciding what to care about. That simple.

And I like the humor.

Here’s a good video summary by the author himself. Disclaimer: Mark Mason does drop F-bombs.

Working Effective with Legacy Code

I’ve read this book when it first came out and have been recommending it to several developers over the years. I felt a need to read the book again and decide whether I should keep recommending it. Short answer: yes.

And how did I do it? You guessed it right: book club!

The book has aged well for the most part, which speaks a lot to a programming book published so long ago.

Many lessons have stuck with me after all these years and I still apply the techniques almost on a daily basis. Some had been internalized so deeply I forgot I had picked up from this book.

Leave a comment

2022: Annual Review

Posted by claudiolassala in annual review on January 6, 2023

Picking it up from were I left of on my previous annual review. This year I’m going with a looser format.

Book Reading

I’ve kept and grown my practice of re-reading books.

I had to read The Accounting Game again out of a need to refresh my knowledge in that domain.

A few books I’ve read again because I’ve been recommending them for years and I wanted to know how well they’ve aged:

Both books were revisited in book clubs with my fellow Improvers.

In another book club, we covered Atomic Habits; one of my favorite books since it came out.

A few other books I simply enjoyed a lot and wanted to read again:

Other book clubs we’ve run that were great:

I’ve improved my book reading process by switching it over from Evernote to Obsidian and am very happy with how it’s coming along.

I’ve been having great conversations about the books I’ve read, as well as putting lessons into practice, pondering on them, and getting better.

My “favorite books read in 2023” post will come out soon.

Life at Improving

Most of my team’s scrum meetings (except for the daily scrum) happened in person. We enjoy getting together to have productive conversations, leverage our big whiteboards, and seeing the other Improvers who come into the office.

Yes, we enjoy coming into the office. Fun fact: there are many of us who work from home on certain days, but end up coming into the office at the end of the day to attend to events, classes, user groups, or to simply hang out. One evening, folks came in to join my “how to write a song” class. Another evening, it was a class for those interested in learning how to play ping-pong. Here’s a great place to learn more about out Community and Culture.

Riding

For the first time since 2017, when I first started riding motorcycles at the track, I haven’t ridden a big bike at a big track. I have, however, ridden the mini-bikes a lot!

The Beyond the Track endurance team has raced all season (I joined as many races I could), and we’ve had a lot of fun.

I’ve also decided to do a few sprint races, which I also have enjoyed.

I plan on doing more sprint races in 2023, and our endurance team has already started our pre-season.

Music

I did some work on my music in 2022 and put out one new original song in 2022: From a Distance.

I’ve had some issues with my recording gear that prevented me from making more progress, but that has been addressed and I’ll have another new song coming up pretty soon. I have a nice backlog of music to work on when I decide to make time for it.

Looking at my YouTube channel, I’ve learned that these were the top 2 most viewed videos last year:

  • Reaching Horizons, a cover of one of my favorite Brazilian bands, Angra
  • Running, a metal cover of a dance-pop band from the 80’s (yup, you’ve got to check that out now, I know…)

This Blog

I’ve put out a good number of posts both at the beginning and at the end of the year, and had a 6-month hiatus in between. These are my favorite ones:

I really liked the series on testing that I’ve put out later in the year. Those posts came out of an “Ask me Anything” Lunch and Learn I presented and I thought more people might be interested in those answers. The posts generated some great conversations in different social networks, which triggered the creation of further posts.

Something interesting I found out looking at the analytics:

In the Top 10 most viewed posts, only 3 posts were published in 2022; all other posts have been published many years ago: the 1st and 2nd place in 2017, and the 3rd place in 2010!!

I have a batch of ideas for posts (some already filled with quite a bit of content), so stay tuned.

Speaking

I started the year by putting a request on social network for people to help me get some of my talks booked as a Lunch and Learn for their companies or as a presentation to their communities and user groups. People answered the call and I got pretty busy talking!

I’ve had a lot of fun, learned a lot from the questions people asked me, and am very pleased with how well the content resonated with many.

These are talks I’ve had the most fun and gathered the best reactions:

  • UX for Devs
  • Effective User Stories
  • Context-based Testing

Go here to get the description for those talks or any of my other ones. If you find something you like, plesae send me a request and I can arrange to deliver the talk either virtually or in-person (Houston and surrounding area) for your team and/or company.

Computer

Since mid-2020, I’ve used a Surface Laptop as my main computer to do .NET work, as my old Mac couldn’t handle the load. Later in the year I got me a new Mac M2 and am very pleased with it.

Two highlights:

  • I was up and running, working productively on my main project, within a couple of hours (most of the time was spent migrating data from my old Mac!)
  • The backend code (.NET Core) has close to 1400 tests (both unit and integration). It takes 24 to 28 minutes to run them on my Surface Laptop. It takes a little over 8 minutes on my Mac M2!!

Coolest thing I’ve learned

I’ve learned a ton of things in 2022. Maybe the coolest one was Obsidian. I’ve been gradually either complementing or replacing Evernote with Obsidian. This is huge for me, as I’ve been an Evernote user since 2008 and it has played a huge part on my personal system. I’ll write more blog posts to talk about how this transition is coming along.

Wearables

I haven’t worn wristwatches in a long, long time. Things like the Apple Watch haven’t appealed to me. But in 2022 I decided to try out the Halo View.

After wearing it all year and keeping an eye on the data it provides, these are the things that I like, and which are making me keep it for the time being:

  1. Information about my sleep: I’ve been analyzing my sleeping pattern, the quality of my sleep, how many hours of sleep I’m getting, and then I look for what has either a positive or negative impact on it;
  2. Activity tracking: I’ve both played tennis and ridden at the track almost every week all year long. It’s been interesting seeing how those activities compare against each other, how they affect my sleep and physical condition, etc.

In closing…

2022, that’s a wrap. There are some great things to look up to in 2023, so off we go!

Leave a comment

TDD? Get a coach!

Posted by claudiolassala in testing on December 20, 2022

Good old fellow speaker Jim Holmes had a great addition to my recent post on TDD tips for scrum teams:

Get a coach to embed with the team–someone who’s got practical, hands-on expertise in implementing TDD in legacy systems.

Trying to get TDD rolling on existing codebases is hard, hard, hard. Having a guide to help the team figure out how to succeed at TDD is critical.

I couldn’t agree more.

I was once asked to work with a team to help them improve their TDD practice. Except that they weren’t practicing TDD yet.

The team had taken a TDD class and started to write as many tests as they could. They said: “our test files are very cluttered, very brittle“. Yes they were.

As the team describes what they are experiencing, it is clear that the tests are written after the feature implementation. Further inspection of the test files confirms that, with signs of copy-and-paste throughout and across several files.

Had the team stayed on that path, they’d quickly abandon tests altogether, as it was getting too hard to maintain those tests and write new ones.

By getting a few sprints of coaching, they learned to:

  • refactor the existing tests
  • identify flaws in the software’s current design and implementation
  • start developing the mindset of test-driven design

Start with a great training course, commit to applying what you’ve learned, and then follow it up with great coaching.

Leave a comment

Evidences that TDD is better

Posted by claudiolassala in testing on December 14, 2022

🚨 Spoiler alert: the evidences you seek aren’t likely to be found here!

There are a number of studies available on the web with numbers, charts, etc. This post does NOT include any of that.

For the readers who enjoy geeking out on studies and researches, here are some great books that include some of that:

What follows are some of my current thoughts on the topic at hand.

Weeks ago I shared some thoughts on this question I’ve heard many times over the years: Is TDD something you do sometimes or all the time? It generated a great conversation with an old fox who has been stalking me for several years. 😉

It started like this:

I’ve never seen good evidence that TDD is better. Oh sure, there are opinions, but not concrete evidence.

That’s a common comment, so I wanted to explore it more.

As a guitar player, I’m often asked questions like “who do you think is better: Tony Iommy or James Hetfield? Yngwie J. Malmsteen or Eddie Van Halen?”

At one point in my life, I’d answer Iommy. At a later point, Hetfield. Then, at another point, Malmsteen. And depending on the day, Van Halen.

It’s all contextual. I’ve listened to a lot of music by those four guys since the mid 80’s. The circumstance, the people who were with me, my personal experiences, all of that influenced who I thought was better at one time or another.

But better at what?!

Record sales?
Influence over new bands and/or guitarists?
Number of hit songs?
Number of memorable riffs and/or guitar solos?
Career longevity?
Guitar playing technique? Innovation?
Caring for their fans?

As the old fox said, “oh sure, there are opinions…”

Over the years, I couldn’t agree with my own opinion, let alone the opinion of others. So who is better?

The fox says “…but not concrete evidence.”

Wait; what kind of evidence are we looking for? I think we’d only know that if we could answer the “better at what?” question. In the case of guitarists, if we’re considering “better at selling records”, that’s something measurable.

But who’s better: a best selling or the most influential guitarist? The latter? But most influential at what?

At some point, I gave up on answering those questions. I’ve let it go. Depending on a number of factors based on a single moment of time, I will deliberately choose one guitarist over the other.

But I digress…

So, is TDD is better?

Better at what? Better than what?

Better at decreasing bugs?
Better at increasing code quality?
Better at bringing clarity to our thoughts before we decide how we want to implement something?

Or…

Better than not practice TDD?
(I can’t come up with any other options here…)

If we manage to add more context to the question, then we can look at the next one, “is there any evidence?”, and define what kind of evidence we’re looking for, and finally look at how we could possibly measure it.

Say the question is, “is TDD better at delivering software faster than not practicing TDD?“

If we’re looking at it only in the context of a very short period, we may find it that it is not.

If we’re looking at a longer period of time, I’d bet it is better.

But we should figure out what we’re measuring besides the time spent writing tests. For example:

  • time spent reading code until we feel confident to change it
  • time spent on a debugger troubleshooting issues

The old fox is wise; one needs to try something before reaching any conclusions:

“I’ve tried it. I can’t say I saw an improvement in the code or fewer bugs. There’s no way to accurately measure that.”

How do we see improvement in code?

There are code metrics we can use, such as cyclomatic complexity (CC), but can one see improvement in code if CC decreases? If developers working on the code can’t yet appreciate low CC, they don’t see it as an improvement.

Occasional music listeners may not appreciate improvements in remastered albums. Many times we need to be trained so we can start seeing (perceiving?) things as improvements. As someone who dabbles at playing classical guitar, Julian Bream’s Masterclass videos has made me hear and see nuances I was respectively deaf and blind to before.

The fox continues:

“But when I wrote code I refactored a lot, not just the code I was writing, but the existing code around it. So that could have an effect on quality.“

That reminded me of Michael Feathers’ Working Effectively with Legacy Code, when he talks about pinch points (here’s a good short description).

But the old fox wasn’t finished:

“I think there are enough developers out there that don’t know how to do unit testing properly. If we want to turn them into TDD devs, first they need to learn how to write good unit tests. Here’s an example: At my last job, I was moved to a team that had little unit testing. They owned code that I was told “It can’t be unit tested.” I showed them it could. Once they’ve learned how to effectively unit test, only then should they be pushed to TDD. At least, that’s my opinion.“

BINGO! That resonates a ton with my own experience. Years ago I even gave a talk titled “I Cannot Write Tests for That!”: UI Edition. I’ve had several similar experiences coaching developers into the practice just like the fox described. I draw great satisfaction from helping developers through that journey, and more often than not, I don’t have to “push them to TDD”; they are the ones “pulling for it”!

Final thoughts for now…

If I am to look for “evidences that TDD is better”, I think of what works for me and those around me:

  • The time spent designing potential solutions to problems is time well spent
    • and it is shorter than the back and forth of implementing features without designing them
  • It’s very satisfying to be able to refactor implementation when there are good specs to back it up
  • The level of willingness a development team shows to embrace changes
  • It feels very pleasant and productive to collaborate with others and have conversations using well-crafted specs

Now if you excuse me, I have some TDDing to do.

Leave a comment

TDD tips for scrum teams

Posted by claudiolassala in testing on November 17, 2022

“Any tips for getting your Scrum team on board with practicing TDD as a team?”

Yes!

  • It starts with the individual
  • Lunch and Learns
  • Try it with one small story
  • Code Review
  • Ping-Pong Pair Programming
  • Divide and Conquer
  • Book Clubs

Expanding each of those points…

It starts with the individual

A few common situations that prevent teams from adopting TDD include:

  • Can’t make time in current project
  • Legacy system that makes it very hard to practice TDD
  • Team members not willing to try it
  • Lack of support from the business

Those situations should NOT prevent an individual to do it.

Practice TDD on your own time so you can build your skills.

If others see you do it, they may join you. If they do, great. If they don’t, you are still growing.

Lunch and Learn

If you decide to take it on your own, offer lunch and learn sessions for your team to share your experiences, struggles, successes.

The purpose is not to wait until you become an expert; share it as you learn.

Make it a recurring meeting.

Write down ahead of time the things you’d like to share (including how and why you failed, and how you’ve overcome it – or not!).

People aren’t showing up or look uninterested? Consider putting it out as blog posts. Why? There are always people out there who will relate to your struggles and successes.

Try it with one small story

Pick one small story, or a small piece of a story, and commit to doing TDD.

You may fail (many times). You may succeed. Either way, share your findings with the team:

  • was it taking too long?
  • Why?
  • Lack of knowledge? Practice?
  • Difficulties with the legacy code?
  • What kind of difficulties?
  • Too many dependencies?

Work as a team to figure out how the hurdles could be overcome.
Your weaknesses might be someone else’s strengths. And vice-versa.

Share the experience at the sprint retrospective. Figure out the next step and commit to it.

Code Review

When doing code review, start by reviewing tests/specs.

When writing tests first, consider asking for a code review before implementing it, to make sure you have a good understanding of the problem that needs solving.

During that review, share any difficulties you see. The reviewer might know how to help you. And if not, you may find a clear path ahead of you just by articulating your thoughts and sharing it with someone else.

After done with the implementation, ask for another code review. This time, maybe share how you’ve addressed the difficulties. Also, maybe discuss ways how the test code could be improved.

Ping-Pong Pair Programming

Consider ping-pong pair programming: one person writes a test, the other one writes the implementation. Then swap.

Set a time-box. Do not let interruptions get in the way.

Let others know what the pair is up to so they can help avoid interruptions during the time-box.

Share the lessons learned with the team.

Divide and Conquer

Work as a team.

Divide the challenges so that each team member can focus on learning one thing, and then share the findings with the team.

Here are some ideas on what to learn:

  • Test frameworks for the tech stack
  • Testing legacy code
  • Tools such as Cypress.io, Cucumber, SpecFlow, Selenium, etc.
  • How to test code that makes heavy use of libraries or frameworks such as Angular, React, Mass Transit, etc.
  • How to write better specifications in Given-When-Then

Book Clubs

Run book clubs!

Build knowledge and skill together as a team.

Choose a book that seems to fit the team’s current skills, set a cadence (maybe once a week during lunch breaks?), start reading, and discuss the findings together.

Here are a few books you may want to consider: Recommended Reading on Testing

In Summary

I have used all of these techniques. Still do.

I pick and choose whichever one works better depending on my current situation. Sometimes the one I pick doesn’t work on a given team. I drop it, and try another one.

Whether the team thinks of TDD as Test Driven Development or Design and whether they use the terms test or spec, that depends on the team’s maturity. Different people, different backgrounds, different ways to learn.

It all starts with one person. Do not wait for that person. Be that person.

,

Leave a comment