“We cannot finish this feature in time. We need to change too much code to do it”. Joe, the technical lead, was always direct and honest.

“What would help?” Bill, the manager, was not happy, but he trusts Joe. If he told him that’s a big problem, he’s certainly right.

“We need to refactor parts of the code”

“How long would that take?”

“I guess about two weeks.”

“Fine, let’s do it” Bill is still not happy, but what else can he do?

I’m sure you have seen this story happening again and again. Usually the team asks for a “refactoring sprint” or “refactoring period” to “cut some of the technical debt”. The manager and the customer has to choose to invest in refactoring or risk schedule variance.

What’s wrong with this story? The developers clearly have good intentions and the managers make the call. But is this the only choice?

Martin Fowler defined refactoring as “a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”. I repeat:

Refactoring means modifying the code without changing its external behavior.

Let me ask you this question: How long do you think it should take to stabilize the application when you refactor? Two weeks? A sprint? One day?

The answer is: 0. Nothing. No time at all.

Refactoring really means that a developer takes a piece of code, makes a small transformation, guaranteed to keep functionality intact, and commits the change. When she’s done with the transformation, the functionality is the same but the code structure has changed.

Chances are if you work in a compiled language your IDE knows automated refactorings. If it doesn’t, you must apply the manual method. The refactoring book splits each transformation in a series of small steps that don’t break functionality. While stopping in the middle of a refactoring is not advised because it usually makes the code structure worse, functionality doesn’t change during the process.

My advice to Bill is:

• Ask Joe to differentiate refactoring from redesign and reengineering.
• Define a criteria for done or you risk wasting two weeks. On the technical side, you can look at indicators like cyclomatic complexity, fan-in and fan-out. On the functional side, you can focus to implement the smallest increment that doesn’t fit into the existing code.
• To minimize technical debt, ask Joe to come up with ideas to cut it down as part of the development. Support him in any way you can.

My advice to Joe is:

• Help developers learn refactoring. Practice exercises described at each chapter from the refactoring book. Try a baby steps session.
• Introduce the boy scout rule.

Refactoring is not a separate step. It’s part of the normal development process. Your manager shouldn’t even know you’re refactoring. He knows you’re developing software. You should transform the code continuously, in small steps that keep functionality intact.

And that, my friends, is what refactoring is about.

In early 1990s, one former US AirForce pilot became Chief Engineer of a software company. The teams he was working with had many troubles while developing a product. Trying to fix the issues, he decided to fundamentally change their workflow. In 1995 he introduced his new method to the world under the name of Scrum. Today, software teams adopting it often focus on one thing: how to do Scrum by the book.

I can only imagine how the world would have evolved if we treated hammers in the same way. Someone needed to bind two pieces of wood together, thought of nails and used a piece of metal to drive them. He shows his method to other people, they all use it and they call it “hammer”. The 3rd annual convention on the topic focuses on making hammers too light to drive nails anymore.

It doesn’t mean that design patterns are bad, Scrum is useless and hammers aren’t helpful. Just that we tend to forget the purpose and focus on the method.

There’s a pattern in these stories:

• someone has a problem
• they find a solution
• more people apply the solution
• applying the solution becomes more important than fixing the problem

Fancy name: “The Purpose-Method Substitution”.

Earthly name: “The Hammer is More Important than Driving Nails”. For short: THIMIDN.

When I coach teams it’s important to find THIMIDNs. I start by questioning the purpose of a certain practice. If:

• I can’t get an answer Or
• The answer focuses on the method and not the purpose

then I nailed it (whoops, pun).

For example:

“Q: Why are you doing the daily Scrum?

A: To answer the three questions”

“Q: How will this feature help your users?

A: We don’t know. The Product Owner told us to add it.”

The greatest risk of a THIMIDN is that teams optimize the method. If the purpose of the Daily Scrum is to answer the three questions, why have a meeting? If the purpose is to use design patterns, why not use AbstractFactories of Strategies aggregated with Adapters for Facades? If the purpose is to develop what the Product Owner says, why understand the users?

I’ve seen agile teams experiencing THIMIDN in a few typical situations:

• Communication blockages
• Shallow understanding of principles and practices
• A company culture that encourages reliance

I use three steps to revert the substitution:

• Clarify the purpose: Why?
• Negate the practice: When not to use it?
• Find alternatives: What else can we do?

For example:

• What’s the purpose of design patterns? To get better design.
• When shouldn’t you introduce design patterns? When the design is very simple.
• What other method can we use to get good designs? Test Driven Development.

So here it is, the brief version of The Hammer is More Important than Driving Nails (THIMIDN):

• You know the method is more important than the purpose when nobody can give you a satisfactory answer to why they’re doing what they’re doing
• Ignore it at your peril, because teams will optimize the method and might not reach the purpose
• Act upon it by clarifying the purpose, negating the practice and finding alternatives.

Just don’t allow the method for finding and removing THIMIDNs become more important than, well, finding and removing THIMIDNs.

Is it true that Ivan Ivanovich Ivanov from Moscow won a car in a lottery?

• it wasn’t Ivan Ivanovich Ivanov but Aleksander Aleksandrovich Aleksandrov;
• he is not from Moscow but from Odessa;
• it was not a car but a bicycle;
• he didn’t win it, but it was stolen from him.

I realized that the same happens with the rule of 5 whys.

This rule states that to find the root cause of an issue in a team you have to ask five times “Why?”. This technique is part of lean methods and was initially used as part of the Toyota manufacturing system. It was then adopted as a tool for agile coaching.

This rule is however a lot like a Radio Yerevan joke. It is very useful but:

• You shouldn’t ask why because it’s annoying and puts some people in a defensive stance
• You shouldn’t ask 5 questions because it might be too much or not enough

My rule is that I ask context-free questions until I am satisfied I understand the problem.

The best resource I could find for context-free questions is the CIA “Phoenix” checklist. I recommend this list to everyone who needs to find solutions to a problem. It’s amazing how it makes people move around a problem and understand what they are missing. Some of my favourite questions from the list are:

• Why is it necessary to solve the problem?
• What isn’t the problem?
• How many different ways have you tried to solve the problem?
• How will you know when you are successful?

The second part of the rule is more subjective and requires experience. JB Rainsberger taught me another, easier to adopt way:

Ask questions until your interlocutor starts thinking

So here it is, use the 5 whys rule but don’t ask why and don’t ask it 5 times. Everything else should be fine.

In those times, there was only one TV channel: the state television. Its broadcast time was 2 hours every evening and included mostly news about Ceausescu, the Romanian communist dictator. We could rarely see sports events. Movies would suddenly stop at 11 pm, when the program abruptly ended.

Across Danube, Bulgarians had much longer and better TV time. As a result, every house and block in the country had manufactured or bought an antenna for receiving Bulgarian TV channels. Of course, the antenna would need mounting and maintenance since it was often moving due to wind, snow or even birds. We would often need to check it, tune it and sometimes build a better replacement.

Immediately after the Romanian Revolution that removed Ceausescu and opened the country to a free market economy, Romanians learned about PCs. A few fortunate people (including me) thought programming and computers were fun so we started playing with them. The others needed help to buy one. You would often see people calling more knowledgeable relatives or friends to help them buy, assemble and install the new PCs. I still do technical support for my family when I have the time.

All these stories have one thing in common. These machines were far from being the best, they created problems and put their users to work. But while working on them, something wonderful was happening. Everybody knew how to fix a Dacia car. Everybody knew how an antenna works and what you need to do to improve its signal. Everybody who wanted could learn how to assemble a PC.

We were all tinkerers, and we all learned a lot about technology.

Compare them with today’s devices. Do you have any idea how your car works? What’s in your laptop? How about your mobile phone?

All devices we use today are black boxes.

Manufacturers are probably making good money out of it, because you need to take your car to the service each year and you would buy a new phone or laptop every few years. But that’s natural, that’s what businesses do and as long as there’s a demand for it there will be a supply.

I have decided long ago to still be a tinkerer, as much as I can accommodate it. I’m not very good at car mechanics, so I am happy to outsource the car servicing. But I know enough about computers to choose the ones that allow more tinkering. I know enough about operating systems to choose Linux not only because it’s free and open source but because it allows me to learn more about computers. My perfect phone would have a physical keyboard, a terminal and a compiler. Unfortunately there isn’t one yet on the market but if I had the necessary knowledge I would build myself one.

I choose to tinker not because it’s easy or convenient but because it forces me to learn how things around me work.

Allow me to end with another story. Last year, I dropped my Dell laptop in an airport. It was before starting a workshop and 2 weeks technical coaching session in Germany. The laptop was my office and my training support material. (Yes, I had backups).

I eagerly opened it just to see a bunch of scrambled lines on my screen. “Oh boy!”, I thought. But there was a hope: the lines were in a pattern that suggested that some piece moved out of its slot.

The first thing I did when arriving at the hotel was to take out my Swiss army knife and open the laptop. And there it was, a module connecting the display to the insides of the laptop that seemed out of its slot. I pushed it back, restarted the computer and everything was fine. My knowledge and choice of technology saved me from headaches. Would I have had a MacBook, my only choice were to call the support and wait.

In the light of all the above I wondered:

Are there other tinkerers? What can I do next? What can anyone who wants to tinker do next?

If you believe in the same things, here are some ways to move the idea forward:

• Write a comment to this post. I would love to start a tinkerers’ community but are there enough interested people? Maybe there already is a community and we can join it?
• Get the Self-Repair manifesto. Print it or add it to your website.
• Join the project for building a mobile phone with physical keyboard, command line and compiler. I am a software developer but I don’t know enough about mobile hardware to even assess if this is possible so any information is useful.

1. You will love programming again

2. You relive the first moments of programming (unless you started with Cobol)

3. You will see how other people write code

4. You will write and speak about code all day long. You’re between friends, accept that’s the one thing you could do for days

5. You come as an expert and leave like a novice

6. To live a paradox: it couldn’t possibly work but it does

7. You experience 3-4 programming languages you never tried before

8. There’s beer after it

9. You could use it to find a new job

10. Pair programming, TDD, clean code, refactoring

10 bis. For Romanians: Romania was the second country in the world to host one

Dennis Ritchie died this week. You probably never heard of him. I never heard of him until today, showing once again that I’m guilty of the developer sin #3. And the sad thing about it is that Steve Jobs might not have become the person we know if it weren’t for Dennis Ritchie.

How come? Wikipedia sheds some light:

Dennis MacAlistair Ritchie (September 9, 1941 – October 8, 2011), commonly known by his username dmr, was an American computer scientist notable for developing C and for having influence on other programming languages, as well as operating systems such as Multics and UNIX.

MacOS and Linux derive from Unix. They are mostly written in C. Either of those might not exist if it weren’t for Dennis Ritchie.

I can understand why the public wouldn’t know the names of great software engineers. I don’t understand how we, software developers, allow ourselves to not know their names, lives and principles. I don’t understand how we allow ourselves to forget history and why we have no heroes.

There’s still a hope: maybe I‘m the only one who didn’t know him. Maybe I need to learn history. Maybe I need heroes.

Somehow, I doubt it.

UNIX is very simple, it just needs a genius to understand its simplicity.

C is quirky, flawed, and an enormous success

– Dennis Ritchie

Steve Jobs was from the beginning in the middle of a revolution that completely changed the world. At that time, it took real courage and burning passion to push for ideas that most people didn’t understand – and yet everyone uses today.

I admire him for keeping the passion alive over the years. His push for quality inspires me. I watch his keynotes because of how he talked.

Most people think of Apple when they think of him. I am not one of their fans, and I believe Steve Jobs created something even better than Apple. He was the artisan who unleashed the creative people of Pixar to create wonderful, touching animated movies: “Finding Nemo”, “Ratatouille” and “Wall-E”, to name just some of my favourites. I for one am very grateful for his gift.

He is an inspiration for me, even though he left us too early. I know something he had moves many other people.

That something is passion.

We don’t get a chance to do that many things, and every one should be really excellent.

–Steve Jobs

I’ve come up with the list below. It is by no means final, and hopefully I can get enough feedback to improve it greatly.

Some caveats:

• I don’t say that all software developers exercise all the time all these sins. Just that most software developers are guilty of at least some of them at least sometime

• A few yeas back, I was guilty as charged on all 7 sins. I still find myself guilty many times of at least 3.

Anyway, here it is:

We, software developers, suffer from the following 7 sins:

1. We are not dependable

   1.1. We ship with bugs

2. We (think that we) are perfect and have nothing more to learn

3. We don’t learn (or forget) our history

4. We don’t value our experienced peers

5. We develop a high tolerance to pain

6. We don’t manage time effectively

7. We don’t take enough care of personal health

Anything to add, remove, fight for or against? Please let me know in the comments.

I used to be quite a gamer. I was playing around 2-3 hours a day on average, and I had 5-6 hours sessions at times. I loved it. I was escaping to alternate worlds, exploring different situations and having a wonderful feeling whenever I was winning.

Not anymore. Now, when I play games from time to time I can’t help myself analyzing them. I see most games as repetitive, dull, without substance. Maybe I learned too much about how my brain works. Maybe I’ve seen more of the real life and games seem artificial. Or maybe games are not what they used to be.

Read the rest here.

The second level of prioritizing happens during the sprint planning meeting. The team looks at each story and tries to see if the story is ready-ready, meaning if the Product Owner says it’s ready for the team and if the team thinks it’s ready to start. So actually the highest business value is not useful at this point anymore; instead, there’s something else.

It’s about information.

The business value is a very good indicator for which stories should the Product Owner work on next. However, the team will waste a lot of time if they start to work on stories that are not ready for development, and potentially be unable to finish them. Doing this also creates a high variation in velocity, since the learning time is different for each story.

So, when is a story ready-ready?

And the best answer I came up with until now is:

When all the questions related to “what are we doing”, except for the trivial ones, have been answered

Here are some examples of questions that you need to look for:

• Why would the user need this?
• What happens if the user does [action]?
• What if the user goes through [another screen]?

Here are some examples of trivial questions:

• What color should the button be?
• What style should the text have?

These last questions are easy to implement during the development because they require very small changes.

So, when prioritizing your backlog, take into account that you will use the information based prioritizing as well, not only the business value.