I’ve been doing retrospection and navel-gazing lately, after deciding to join a new adventure and leaving an awesome job. I had the chance to work in XIV-IBM for just over a year, and it being my first real job I was thinking of how satisfied I am with my work there.

As I’ve mentioned in previous posts, it’s not easy taking the software craftsmanship road when joining a team with a large code base and practically zero tests. I joined in order to help introduce automated testing to the team’s development process, but making these changes is never easy.

I recently read an amazing book called Apprenticeship Patterns, which collects the different patterns we share in our industry on our track to professionalism. Of those patterns, reading “Unleash Your Enthusiasm” suddenly made me understand more clearly what I’ve been doing that year.

When I just joined the team, I naturally tried to get the vibes of the team and “go with the flow”. The first small projects I did on my first few weeks to get my feet wet weren’t a craftsman’s best work, to say the least. I barely wrote any tests, and since Python doesn’t have decent refactoring tools, that made me refactor less. After a couple of weeks I was already getting angry with myself, and once I noticed thinking of changes to the code made me twitch it was clear something was wrong (after all we’re all for “embracing change”, aren’t we?).

I decided to return to the good path. Catching up on some best practices for unit testing in Python and adopting once more the Red-Green-Refactor cycle did the trick for me. I haven’t stopped TDDing since and didn’t look back. But here is where the story got more interesting.

Working on a project mainly by myself meant I had it easy in making sure the code base is tested the way I liked it. My manager thought, as a good manager does, that as long as the outcome is good he shouldn’t care if I do something no one else on the team does. This allowed me to have my fun, but still something was missing. I really found it hard seeing my teammates having troubles that could have been easily avoided with a good suite of tests. More than once I saw people in a debugging spiral or fighting a refactoring gone wrong.

Being the loud-mouth that I can be, I made sure to help people see how much fun I had writing code as code was meant to be written. Parading my Clean Code wristband, posting certain manifestos on the walls and sending the team links or snippets was a good start.

After a while, some people wanted to hear more. I gave a unit testing talk that pretty much got people hooked after I deleted random lines of code and showed them the tests captured it every time, and the knock out was Gary Bernhardt’s awesome kata that showed TDD won’t slow you down.

Seeing that team’s lack of testing slowly transforming to a suite of tests that kept getting closer and closer to the FIRST principles made me understand how a young developer can really unleash his enthusiasm to make real changes happen. No one has made the jump to TDD yet, but I think the whole team can be proud for adding hundreds of tests to their code base in less than a year. Remember, if you work with excellent people, sometimes all it takes is a little push to get them on a better track.

This taught me yet again that being a craftsman is about sticking to your principles. Craftsmanship of Crap all the way.

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

This is another post in my book reviews series. I finished reading Clean Code a few days ago and loved it. It makes me feel good, seeing my decision to wear the Clean Code wristband a few months ago was a smart one.

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.

I’ve been practicing TDD for a couple of years now, and keep learning all the time.

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!

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.

And now, to the gory details. Buildbot has a built-in class for executing shell commands, called ShellCommand. Now let’s say we want to create a class, VerboseCommand that always executes commands with the -v flag. One would assume this is the right way to do it:

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!

Note: this is a technical post, to help poor souls that google this :)

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.

Ensuring that you’re aware of known behaviours is crucial, as it prevents you from looking up issues with software unnecessarily. Of course, you can find these out on the web and it’s not difficult to test run them if you’re unsure what they’ll entail in terms of reversing the process or even repairing a bug or glitch yourself.

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

Coders are the worst customers ever. The sooner you wrap your head around that, the better. Actually, any customer that’s technical is a bad customer, but nothing trumps coders. That fact is not intuitive, or at least wasn’t for me, but it can be really painful to find it out by yourself. So here, I just saved you some agony.

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.