After I finished it, I felt a bit weird writing a blog post about it, because, just like the previous books I’ve blogged about, I found this book simply awesome. Then I thought about the fact it’s simply because I’m reading those books that show up enough in other contexts that I upped them in my reading queue enough to get on top.

The book is about practical, low level details of writing good code. There are chapters about comments, naming, functions, you name it. In a way, it reminds me of Code Complete, other than the fact you can see it’s oriented for more practiced developers.

Like in his Agile Software Development book, Uncle Bob made sure to fill this one with code. Actually, this book has a lot more code. There are many examples of code still being worked on. It actually fills the gap I’ve felt in Agile Software Development of seeing the actual coding steps, test by test. The last chapter shows a really thorough (and actually quite mesmerizing) example of refactoring, with each change explained beforehand, including tests and alternatives considered.

In Agile Software Development, there were a few co-authored chapters. In Clean Code Uncle Bob took this a step further. Almost every chapter was written by a different author, each of very big caliber in the Agile and Software Craftsmanship world. This really resonated with me, because it’s kind of a “many in one” deal, and because I could actually hear a different tone in each chapter, and yet all were in harmony with the motive of clean code.

I think this is truly a masterpiece, and after reading, would recommend it to be read before Agile Software Development. Due to its greater technicality and the fact it’s quite new, it makes a really good read for developers, and it will have an effect on your coding a few pages in (pages! not even chapters).

The only thing that bothered me was that in the last chapter (which is also the best) I had to, as the introduction warned me, flip back and forth quite a bit, which was a bit hard at first since I’m not used to reading code on paper. I’d really love seeing some interactive version of this, but regardless of that, the book is really good.

I can’t recommend enough this concentrated piece of wisdom and experience.

Stay tuned, a review of Apprenticeship Patterns is nigh.

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

In the past year I’ve been mainly working on a single project, the longest I’ve worked on a project with TDD. Putting aside how fun it is (TDD saved me quite a few times for me to be sure it’s worthwhile), working on a project for so long I finally got to see some of the main problems people have against TDD.

With the hundreds of test you have, refactoring on the class-interface level (that is, the interfaces of classes, and not inside classes) can be problematic, with you having to update all the tests.

I’m still learning how to handle this efficiently, and would like to share an experience I had today. This is an example of a problem regarding 2 collaborators and an interface change. Such refactorings in a TDD environment weren’t mentioned in the excellent “TDD by Example” book and similar works, so I’m pretty much guessing here.

The example:

The change we’re interested in is making “eject” simply open the lid, without rewinding, and making the rewind operation public. This is in order to allow LazyPerson to take the tape out, without having to wait. Gary Bernhardt wrote about this kind of changes a bit. I agree, the fact I need to make such a change is against the OCP. What can I say, I’m not perfect and made a design mistake. Saying “that’s not OCP” doesn’t help me – I’ve got this code and tests, and I need to change them.

I used to succumb to the temptation and make all the changes in one sweep. That means changing all the tests and the classes, then running the tests and hope they still pass. This, of course, is a crappy way of doing this. Had I been able to actually perform such tasks, I’d write less tests. The secret is baby steps. The pressure Kent Beck puts on baby steps and gradually working towards change made me consider this and force myself to find a safe way of doing this.

I decided to start with the VCR and its test (the AutomaticPresenter doesn’t use the VCR itself but an interface, and the tests use test doubles. This means changing one part won’t break the other’s unit tests). The path to enlightenment lies in finding the baby step that allows starting the refactoring without breaking the rest of the tests. I decided to add a test for the should-now-be-public “rewind” operation, while not breaking the existing tests.

The solution is adding a default value for telling the “eject” function whether it should rewind or not. This means existing users (be them tests or not) will still get the previous behavior, and new tests can start work with the new interface (in Java I’d probably do this with method overloading):

This got me to green pretty fast. Now I can slowly remove every rewind-related assertion from the old tests and also add the “should_rewind=False” flag to them, all with quick-green cycles. And we’re done with the first half.

The next move is to change the AutomaticPresenter to call “rewind” before “eject”, which is now really easy to do in the tests. Once we hit green, we remove the “should_rewind” flag and be done with the refactoring. Baby steps save the day:

Being able to get the refactoring working so easily makes me happy, but I’m still not sure this is the smartest way, and there are harder refactorings to master ahead. Yet, I hope this will help TDD adopters see that it’s possible to handle refactorings even with many tests, because once the right baby-step is found, each test can take practically seconds to convert.

I’d really love getting feedback on this cycle.

You should subscribe to my RSS feed or follow me on twitter!

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!

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!

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!

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):

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!

When using nose on Solaris machines, simply running nosetests without specifying the file names will not work if you are the root user. To fix this, you must either not be root, or pass nose the argument --exe. That’s it.

Gory details: by default, nose ignores executable files. Each file it encounters it checks with os.access(test_file, os.X_OK) to see if it’s executable. Problem is that Solaris’ access function always returns success for root, regardless of actual file permissions. This is discouraged by POSIX, but known behavior.

I hope this saves someone the 3 hours it wasted for me

Why are coders bad customers? First, let me say that even though coder-customers are a hard group to work with, they usually have really interesting problems to solve. After all, if it was simple they’d usually do it themselves. But, being coders, they think it’s acceptable to tell you how to do your job.

When you work with coders, the usual ticket/email/water-cooler chat will be of the form “you need to add an option for specifying X of type Y instead of the current options”. At this point they’ll usually start telling you how to implement that and how easy it is. If you’re like me, at this point your instinct will be to crank out the code and make your customer happy. Resist that urge like the plague!

Whenever I receive such a ticket, I dismiss everything in it. What I do next is come up to whoever suggested it, and ask “What is it that you’re trying to do?” Usually, this will result in exactly the same technical do-this-and-that explanation. Take a deep breath and ask the question again. This will usually be enough, but sometimes may require a couple more tries. That’s how you’re supposed to gather requirements – understand the problem at hand.

The main advantage of being a pain-in-the-ass and making sure you understand what it is you’re supposed to implement is because every coder should know exactly what his code is doing. A lot has been said about understanding the domain you’re working in, and simply implementing things handed to you is not the way to become knowledgeable in your domain.

Furthermore, once you hear what people are trying to do you might think of a better way of doing it, you being fully immersed in the existing code. Actually, more often than not you’ll see it’s actually already possible to do it! And best of all, you might simply decide that’s not a fair use of your code, and reject the ticket. How could you have made such a decision without knowing the actual problem you were asked to solve? No way.

Saying “no” to features is one of the most important design skills to master, and a tricky one. After all, turning to your keyboard, hacking the code and saying “presto!” is more fun at first. But that way of working leads to a code-base that you don’t really know. I’ve seen systems that were driven this way by technical users. 3 years later, there were rogue database fields that no one knew why there were being updated, and weird log files in awkward formats. Whenever someone tried removing one of those he found out it broke some dusty cron-job that seemed to use it instead of doing something sane (and do I really need to mention the code was a tangled, convoluted mess?).

Ask why, mindfully consider and then decide. There’s no really other way, unless you’d like to meet Code Cthulhu.

You should follow me on twitter.

Up until 15 years ago, I think it was very common for people to hack away at code for a good length of time, and once they got enough done, they’d try and compile the damn thing and start correcting the syntax errors, import things they forgot to, etc. This probably was because 15 years ago is the middle ages in computer-land, and compiling constantly was something people couldn’t even dream about on the little PCs we used to code on.

Nowadays, you can’t find more than a handful of static-language coders that won’t use a full featured IDE. C, Java, C# – other than a few freaky kernel hackers, I doubt anyone does real development outside an IDE in those languages. Today’s IDEs will tell you that you made a mistake about 2 seconds before you did. I never stop being amazed at how smart Eclipse is – and the first time I had to whip up some Java code in Vim, I felt handicapped.

What I find puzzling, is that people that are using the best available languages today, have suddenly decided that using the proper tool isn’t that important. Dynamic languages like Python and Ruby are not as easy to write awesome IDEs for, and therefore there aren’t many around that are mature enough, which is why it’s very common to see people use Emacs/Vim for coding them. Now don’t get me wrong, I’ve tried a few Python IDEs, but I’m still sticking with my Emacs. But when you use dynamic languages, you have to keep in mind you are even more prone of errors that will slip by. Even if you TDD, and your test coverage is extremely high, a typo might still get past your tests. Do you really want a production failure because you forgot to import an exception? (And do you really want to upset Agnes?)

About 2 weeks into my decision to stick with Emacs I started searching for simple tools that will protect me from my stupidity. It takes 10 minutes to find and install flymake with pyflakes (Python tool) support. Presto! No more typos in variable names, no more useless imports lying around. What surprised me is that a lot of my teammates, which I have respect for and are good programmers, did not use any of these. Time and time again our continuous integration system will report an error on a file and once I opened the file Emacs would show me the bad line marked with red, with no way of not noticing it.

I don’t like wasting my time, and I’m sure you don’t either. Stop being lazy (in the bad way). Stop making me angry. Get out of the middle ages. Yesterday we got everyone on my team to add pyflakes to their vim. Took 3 minutes to install. The problem is that it took more time to get them to install. “Nah, Vim already highlights syntax, there’s no need for more”. Oh really? After 10 minutes of searching I found a file that pyflakes showed a real problem in, and another, and another. “Hmmm, where do I download that plugin?” Win!

Do yourself, your team and your build slaves a favor, and start using some modern tools. I promise it will be worth it, money-back-guarantee. And remember, if your team is still churning butter, sometimes all it takes is a little push (and sometimes you can plant bugs in their files).

You should follow me on twitter.