Developing Software Together

“How did you refactor that?”

After my video about “Primitive Obsession”, a viwer asked me on Twitter how exaclty I refactored the code towards the final result.

Which steps did I take? Which transformations did I perform in the code?

In this video, I want to show you how I would refactor this piece of code to get rid of the primitive obsession.

Quick show of hands: Who here likes retrospectives? Who loves them?

Many people I have met so far would have kept their hands down. They would rather work on the next feature than sit in a retrospective.

That’s because, in many teams, retrospectives are boring and ineffective.

Did you ever see some piece of code that uses primitive data types, like Strings or integers, in it’s public API? I am sure you have, because most code is written like that.

But that can cause problems. Today, I want to talk about a code smell called “Primitive Obsession”. And I want to show you how code often becomes easier to understand and “nicer” by eliminating primitive data types - especially, but not only, from it’s public API.

Do you remember how you first learned about object-oriented software design? How they teach it at University?

You probably looked at objects from the real world and their is-a or extends relationships. A circle is-a shape, and it extends shape. A cat is-an animal, and it extends animal.

Today I want to re-visit this kind of approach to learning object-oriented design and discuss it’s advantages and shortcomings.

Test Driven Development, or TDD, seems to be very popular among some software developers, but most of us are still skeptical and not using it.

Those who use it say that TDD helps them to write better code faster. Those who do not use it often say they have tried it and it does not work.

How can some technique be very helpful to some people and not work at all for others? I think a part of the reason is what I used to call the “mock objects trap”, but now call the “TDD trap”…

Did you ever hear phrases like “Agile is not faster” or “You need to do un-intuitive things to become agile”? Did that make sense to you?

To me, in the beginning, those phrases made no sense at all. But now I think that they are the main reason why so many companies do not get “agile” right. They “do” agile only to become faster. But they do not “get” some of the most important underlying principles.

Today, I want to talk about a very important but also un-intuitive principle: You must slow down to move fast.

How can you, as a team, start with continuous improvement when your company does not want to give you enough time? And if they do not give you a budget to spend?

A learning lunch - where, once a week, you use your lunch time to learn something new - can be a great starting point. And it requires only a small investment of your team members’ personal time and money.

When we give a size-, effort- or time estimate, like “5 Story Points”, “7 ideal engineering days”, “this will be finished before End of May”, what does that actually mean? And how useful is the number?

That depends on what question we are actually answering with that number…

A lot, it turns out. Or, maybe, not “go wrong”… But the result you get might not be the result you expected.

This article is part of the series Planning Software Development.

Suppose your team must estimate the effort of the work packages (User Stories, …) it is supposed to work on.

This article is part of the series Planning Software Development.

When we develop software, people often will ask us questions like: