The Code Dump

Have a habit of apologizing for your code before showing it to someone else? You’re doing it wrong.

I’ve been the only TDDer in my team for about a year now. When I just joined the team, my TDD ways were looked at as a weird fad. Nevertheless, I kept working in my ways, know that, at least for me, it works best.

Working like that can be very frustrating. You make sure your code is clean, well tested and refactored. Then comes along someone that makes a small change and your tests no longer cover that part of the code. You open up some other part of the system, see bad code and though you try to follow the boy-scout rule, you can’t because you’d need to harness 10 computers and a goat to test the code in its current state.

A few months ago I asked Uncle Bob what is a programmer to do in such a situation. His response:

It’s frustrating and difficult. But what choice do you have? All you can do is keep at it. Shame the others by keeping to your disciplines.

And boy was he right. As months passed, and people glancing over saw me running hundreds of tests in a second and being able to make quick changes without fear (or very little), I noticed a weird pattern.

Whenever people asked me to lend them a hand with a piece of code, the presentation of the code started with a disclaimer: “Never mind how ugly it is“, and “I know it looks bad”.

At first, my ego always happy to boast, I took it as a compliment. Later, it dawned on me that it’s not that my code looks like pure prose simply because it’s TDDed.

What that apologizing means is “I’m sorry I don’t care about the code as much you do“. Uncle Bob was right, people were actually ashamed. Sounds weird right? But then again, if you do care, why haven’t you removed the need to apologize after the second time?

Get out of this shame-phase. Being ashamed means you care, do something with it. The next step is simply making the code cleaner. Some of my team-mates have already started down the enlightened path.

Remember, coding is a social activity. When you disrespect the code, you disrespect your friends. When you rock on, you all enjoy. As a wise man said, keep working on your code till you’re ready to project the code onto the wall for the whole team to see.

And if you’re in my shoes, keep it up. Sometimes all it takes is a little push.

You should subscribe to my feed and follow me on twitter!

Today I had the honor of running a Code Retreat right here in our little country.

A Code Retreat is a concept that was born in the beginning of 2009. It’s a day that consists of a bunch of programmers working in pairs about a problem – a session is 40 minutes long and after each pairs rotate and the start from scratch.

This code retreat was a bit special. It wasn’t a public one. My previous employer liked the concept and I was asked to help with running one for some of their coders. The group consisted of 15 coders that are in the company at least 2 years.

Most of the people don’t pair at work and none TDD (only some unit test). Because of this we’ve decided before starting not to make TDD a must, but introduce it and encourage trying it out.

One of the things that surprised me was that after 3 sessions, some people asked if it was possible to get a different exercise. I haven’t heard of a code retreat with more than 1 exercise and I’m puzzled why this team has brought this up. Currently, my only guess is that the Israeli temper and to-the-point attitude (“Dugri” or “Takhles” in Hebrew)  caused it (even though there were many wicked implementation ideas running around). I’m still not sure giving them another option was a good thing, as I believe squeezing more ideas from one exercise is where things get really interesting (and some preferred staying with the original one).

Another point was that some people said they would have appreciated more structure/direction – what to do in each session and getting a list of implementation ideas for Game of Life.

We were also asked for longer sessions – 40 minutes felt like too little and our single 50 minutes session felt more like it.

A bit unsurprisingly, when we performed the String Calculator Kata to demonstrate some TDD, most people thought this was going overboard with tests for such a simple thing. I hope some got the message and I think that the fact we actually had bugs caught instantly by the tests helped!

To sum it up, I think that all-in-all people had a good time. I practically had to pull some from the keyboard at the end of sessions. Can’t wait for the next one! I’m thinking of getting a bunch of Clean Code wrist bands to give away.

For future reference, here’s the list of Game of Life ideas people have tried:

• Cell centered
• Board/Universe centered
• if-less (as possible)
• Uber-threaded (each cell is a thread)
• Performance-centered (board is a byte array)
• Focus on the neighboring-connection (the “lines” between cells)
• Implement in a few different languages and their idioms (we had Java, Python and some C)
• Different topologies (hive-like and 3D)
• Calculate results by hashing certain parts of the universe and the expected results for them

And, the second problem that was given is the Poker Hands Kata:

• Go through the cards and seek the best hand
• After each card is added to the hand, hand-types that are no more possible are removed
• Encode the hand as a 64bit number, and then find better hand by subtracting the numbers

You should subscribe to my feed and follow me on twitter!

Having recently finished the amazing PPP book (more here) my code-sense is getting better in putting the finger on the smells in code that make it painful for me to use. This is the story of one of them, in Buildbot.

Disclaimer: Buildbot is a pretty awesome building/continuous integration system that I use and contribute code to regularly. Indeed, it is far from perfect, but none of the coders should take offense.

So, what is the Single Responsibility Principle (SRP) ?

A class should have one, and only one, reason to change.

If a class has more than one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

But this turns out to be wrong. Say we tried to execute ‘nosetests‘, the actual command that will be executed is ‘nosetests -v -v‘ (which is harmless, but you might have guessed my real use-case wasn’t adding the ‘-v‘ flag). The reason is, as the Buildbot manual will happily tell you, that every step is also its own factory.

Wait, what? Given the fact the a certain step will need to be run in multiple builds on multiple slaves, a new one needs to be created every time. But, as a user you only instantiate the step once. Turns out that behind the scenes, Buildbot will save the arguments given to the command’s constructor and call it with them again every time it needs a new instance.

This means that in our case, we must find a way to tell in the constructor whether we’re instantiating the factory or being instantiated by the factory, and add the flag only in one case but not both. My cute example turns to this mess:

(If you’re really bothered with understanding every detail, read the manual, but I’m sure you can get the gist of it without doing so.)

Now, if you’re anything like me, you’re looking at this and wondering something along the lines of “what the hell were they thinking?“. That feeling, that tingling in your code-sense, is the smell of an SRP violation.

Because this class has to also act as its own constructor, the coupling between the two actions is high, and as the definition clearly states, the class now has 2 reasons to change.

Surely, separating this to 2 different classes (the actual step and a factory) will have solved this problem elegantly. Given that this might be considered “advanced” usage I’m willing to accept that creating a factory will be optional. But really people, this addFactoryArguments screams HACK.

If you liked this post, you’ll definitely want to read the PPP book.

You should subscribe to my feed and follow me on twitter!

Once we got our builds happily running on Buildbot, there’s really no reason not to add coverage since it’s so easy (especially if you get bragging rights over your non-TDDers teammates).

All you have to do is this (code is based on this blog post, with adaptations to work on slaves that don’t share directories with the master, since the createSummary method runs on the master):

How often do you get to work along some coding superstar that’s been at it for decades? If you’re anything like me, the answer is “never”. That’s why I’ve recently decided to go after books that are aimed to fill this gap exactly. The latest is “Agile Software Development: Principles, Patterns, and Practices” by the one and only, Uncle Bob (the previous is “TDD by example”, which gets 5 stars from me too).

It’s like coding with the Uncle himself

The thing I liked the most about the book, is the way it walks through (relatively) huge amounts of code. Uncle Bob shows several programming problems and walks through his design process and the implementation of the interesting parts. Reading it (even though it was written almost a decade ago) you can’t miss the fact the author has so much experience. Whenever I tried coding a solution myself before reading on, I later found out exactly where I went wrong because he somehow managed to cover every decision I made.

When I say it’s like coding with him, I really mean it. I don’t know how, but whenever I looked at a code sample I didn’t like for some reason, I was astonished to read “You may be wondering why I did X” the next paragraph. And, maybe less fun, is when I read something, totally agreed with it, and he went on to explain why it sucks.

The feeling throughout reading the book is that you get to pair with one of the best software craftsmen ever.

You get experience in every paragraph

A big part of the book is dedicated to talking about XP and design patterns. I’ve read several books about both and yet I didn’t find those parts in the book redundant. The reason is because Uncle Bob has managed to put a few grains of experience into whatever he talked about. Even though I’ve coded my fair share of Factories, he made me realize a few interesting concepts about them. And although I’ve done Visitors, I suddenly am a bit in love with them (which means I have to fight myself extra-hard not to introduce them everywhere).

If you don’t have people around you that care about coding a lot (enough to send out awesome Clean Code wristbands, one of which I own) you’ll quickly grasp what I’m talking about. The whole writing is of an experienced mentor (which might explain why his company is called “Object Mentor”).

It simply changes the way you look at coding

Having gone through the SOLID principles, my whole designing process and way of thinking has changed. I can’t think of a sane developer that will refuse to put his hands on a set of principles that the best coders of the past decades have deemed as necessary for quality code.

Do yourself a favor and get your hands on this piece of software-craftsmanship gold-mine!

Stay tuned for the next part of this series, Uncle Bob’s Clean Code!

You should follow me on twitter and subscribe to my RSS feed, it’s free!