Recently we finally made the move to a GitHub organization. For the past 18 months or so we’ve been using private repositories on our CTO’s personal GitHub account. Having reached the maximum number of allowed collaborators on a personal account, we decided to make the move.

Basically, it wasn’t that big of a deal at all, but since I couldn’t find any writeup describing it I thought I’d throw it here.

When you want to create a new organization, you can either choose to transform your own account into an organization or just create a new one. We opted for creating a new organization for BillGuard in order to avoid causing Raphael an identity crisis.

The steps were amazingly easy:

1. . Create a new organization.
2. . Add to its owners whoever needs to be an owner (up till now you had no owner except for the actual account holder).
3. . Create a team for everyone that needs access to the repositories. We started simple with a team for developers that allows pushing and pulling.
4. . For each repository that needs to be migrated go to its Admin section, choose “Transfer Ownership” and move it to the new organization.
5. . Now everywhere you have a migrated repository cloned needs to run this simple command: git remote set-url origin git@github.com:ORGANIZATION/REPO.git

That’s it! GitHub magically moves the different web hooks, server deploy keys etc. that were configured on the repositories so they keep working.

Some things to note: In case your repositories have been forked, you need to contact GitHub support to change roots as described here. Also, you might need to change repository URL someplace else like your CI servers.

Happy git hacking!

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

Earlier today David Brailovsky and I gave a talk at the Israeli MongoDB meetup. Below you can find the slides.

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

If you write a test and it passes, the question is if the previous step was too big.
The DRY principle doesn’t talk about code, but knowledge.
Clever is never something to be proud of in your code.

A couple of days after attending the code retreat facilitated by him, I was fortunate to attend Corey Haines’s “Improving Your TDD” workshop at the Agile Practitioners 2012 conference. These are some of my notes from the day.

The workshop was intended at coders familiar with TDD and not introductory. I was very interested to see how in-depth TDD training looks, and also meet other coders from Israel that have been doing TDD for a few years. It was quite awesome to sit in a room where everyone felt comfortable with TDD and it wasn’t this new and hard thing. When the group shares this “advanced” technique, discussion can suddenly level up and we could all dive in to the nitty gritty stuff.

During the day, Corey walked us through pretty much taking TDD apart and putting it back together. We started from the history of TDD and its predecessors (manual verification, test after, test first, etc.).

The exercises throughout the day (that I especially enjoyed since I was pairing with @theyonibomber, my original pair as we were learning TDD together back in 2006) had this beautiful flow of making you smack right into a problem in the way most people do TDD.

We discussed having the tests drive an implementation that we knew we did not want (like sorting easily become bubble sort) and how the (relatively new) Transformation Priority Premise by Uncle Bob can help solve this.

We then took another introspective look at our TDD process (aided by an exercise once more) that made us face the problem of “flailing” and “sitting in red” – basically the problem of trying to take a step too big in the next test and so falling off the good fast rhythm of “time to green”.

We had a long discussion about these problems and how they are directly connected to the way we pick the next test. We all know that the next test should be the “simplest thing”, but how exactly do we define simple?

I love having these discussions that jolt me and make me rethinks stuff I’ve long ago stopped paying attention to. Developer introspection is a thing of beauty and much power (Kent Beck tells that he wrote his incredible Smalltalk Best Practice Patterns and Implementation Patterns books by simply stopping whenever he was about to type some code and have an explanation as to why he picked to do it that way).

Corey even did a live demo of his TDD style and programming by wishful thinking. It was very interesting, but as all live demos go he had some trouble along the way. Workshop aside, it is not trivial for someone giving a training to admit a mistake done, and Corey gracefully handled the situation.

All in all, the day was a very productive one and it still has me chewing on some of the lessons we learned. It’s fun realizing again that there’s no limit to how much one can sharpen a specific skill. Hat off to Corey and the conference organizers for making this happen!

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

A month ago I had the great pleasure of participating in a Code Retreat here in Israel, which was facilitated by the amazing Corey Haines. The event was so awesome and fun that I just put together a few tidbits that I think are worth sharing.

This was actually the third code retreat that I took part in, but funny enough the first retreat where I was a plain participant. I’ve facilitated two code retreats previously, one at the Global Day of Code Retreat 2011, and one internal retreat at the IDF unit I used to serve in.

I wasn’t sure going to a third retreat would provide new take-aways, but it sure did!

The first thing that was different from previous retreats was that Corey shared his views on coding. I was already familiar with most of the ideas that he mentioned, but he has a way of making ideas seem simpler that I originally thought, which is very powerful. I also loved seeing how other developers less familiar with these concepts reacted to them.

I was surprised the problem can still be interesting after a couple dozen attempts. This is something I never thought I’d see. I’ve seen the code retreat problem (Conway’s Game of Life) solved a few dozen times previously, and wasn’t sure I’d still get a lot out of doing it a few times again this retreat. To my astonishment, every pair I worked with in the retreat brought with him new ideas and considerations, and Corey had us focus on different aspects of programming in each session (there were 5 sessions).

I’m amazed that we could write the little function that checks whether two cells are neighbors in so many ways and still think hard about it. In one of the sessions, my pair, Elad Sofer, and I were debating the cleanliness of using euclidean distance for this back and force. Corey stood and listened to us talking, though we were speaking Hebrew and he couldn’t get too much out of it. When I asked him if he wanted us to switch to English, he had this Neo moment and said “I think I understand what you’re talking about” and a minute later he just chimed in and helped us point out the part of the code that wasn’t fitting in. Such a discussion over 2 lines of code – FUN!

In general, I loved seeing the spark in people’s eyes and the full power of passionate developers, talking, discussing and caring about their code. As someone who cares about each and every character in source files, I had a blast being around the passionate people, all bathing in the glory of the joy of programming.

Putting limitations on our code as we were solving the same problem kept making it appear as a total different problem. The things you can do when you’re strictly adhering to the 4 rules of simple design are so different of those that appear when you and your pair aren’t allowed to speak and just communicate via the code and the tests (no comments allowed! (which is always a good rule)).

Another reason I had a blast was that because, to be honest, I picked the pairs I really wanted to work with, having only 5 precious sessions to work with people I never get to work with regularly (though given 5 more sessions, I would have liked to pair with a few more of the people who attended). Working only with people that I knew were awesome, though not necessarily worked with before was a great boost. My awesome pairs were alonhorev, avihut, yonbergman, pembleton and eladsof.

We did TDD in all the sessions, but it was fun sometimes working with people out of their comfort zone, seeing how they react and how I had to be clearer. Sometimes it was just a matter of working in an editor they’re less familiar with, and sometimes I had to teach Ruby while we were at it. Having to formalize in words every thing you do has the power of making you aware of a lot of the little decisions you usually make unconsciously, which is always a great thing. And I loved picking up little tricks I didn’t know from my pairs.

All in all, the retreat once again proved out to be an awesome opportunity to focus on the fact that we’re all doing this because we love coding, and reminding us that it’s fun and that we can always learn and become better at it.

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

I’d like to point out a really nice testing practice that I’ve been loving more and more lately.

Just about every mature testing framework out there supports the concept of custom matchers, which provide us with the ability to define our very own assertions seamlessly into the tests. Even though this ability is quite old, we don’t see it used too often and I think that’s a shame. I’ve seen this practice heavily used in the mind expanding GOOS book and just now am starting to realize its awesomeness.

Note: examples in this post are shown in Ruby using RSpec’s matchers but the concept is pretty much identical (as can be seen for example in Java’s Hamcrest Matchers).

Matchers 101

Creating your own matcher usually means creating a Matcher class that performs the assertions, supplies human readable error messages and a nice constructor.

Here’s an example from the RSpec documentation:

Matchers increase readability and intent

As you should know, one of the most important rules for design is Reveals Intent. Take a quick look here, which way do you think reveals more intent?

Also, which error message do you prefer? “expected false to be true” or something along the lines of “expected comment to be anonymous”?

Matchers create robust tests

The most important advantage of all is how using matchers easily allows you to steer away from fragile tests which are the bane of a lot of testing efforts. The mark of good tests is that a change in your code doesn’t require you to perform changes in multiple tests that don’t really care for the change. Take this code for example:

This might seem like a standard test, but that’s not really the case. A test should assert for a single piece of knowledge, and this test actually checks several. If the purpose of this test is to check the behavior of anonymous comments, why should it change if we no longer allow replies? Or if we no longer require users for posting comments?

The magic of matchers is exactly here. You create a new matcher to check specifically the aspect your test cares about and boom, you’re decoupled!

This simple change makes your tests DRY and cool.

Happy testing!

Your should subscribe to my feed or follow me on twitter!

Continuing on this series of the Autonomous Craftsmanship Core we now reach the methodology problem.

“I want to do agile/craftsmanship/etc.”

The key is basically to put the rest of your team aside and focus on how you can do things like you think they should be done. You want to do “agile”? Open the manifesto, read the values, and think on how you can change your own process in order to further yourself the direction you want to get.

Development Practices

This one deserves a post of its own, but luckily for us I’ve already written it! You don’t need permission to write tests, use the right tools, and just coding in an awesome manner.

Your own mini iterations, planning and retrospectives

I think a big part of becoming a better developer is looking at how we work, analyze it, decide where we need practicing and then getting better at it, deliberately. Here are some examples from my own development process.

Pomodoros

I love pair programming. Love it. Love it so much, I find it hard to be productive without a pair when coding. I find that the crazy simple Pomodoro technique is some kind of magic makes-me-focus-real-good drug. Anytime I’m doing tasks on my own I set up my little timer and burn down the todo list. Using pomodoros allows me to keep track of my time, focus, see how good are my estimations and waste less time on reddit. You don’t need anyone else on your team to “allow” you to do pomodoros. Just do it, and see magic happening.

Goals and Retrospectives

Just like in an agile team we plan sprints, have retrospectives and set goals, I do the same for myself, both at work and for my personal time. Every week I do a retrospective of the past week, think what I did wrong and what I like. I have monthly and weekly goals. I’ve got recurring tasks in OmniFocus to review my work. I write the reviews in Evernote and then create new goals and add them to OmniFocus. That way every week and month I can go over the last few weeks and see how I’m doing. For example, I can set goals for finishing a book, write some blog posts, communicate better at work, etc.

It’s up to you

Uncle Bob Martin said it’s not your boss’s responsibility to make sure you learn and become better, it’s yours. Once you realize this, stop waiting for things to get better by themselves and step up you can actively become better. I was surprised how many of these aspects coincide with what Seth Godin talks about in Linchpin. You have no excuses not to be doing better things. It’s you’re responsibility, so stop bitching and do awesome work.

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

As we’re approaching a year and half here at BillGuard, I’ve started thinking back a bit about our testing habits and how well that’s turned out.

I’ve seen a lot of posts about testing in startups, some saying startups shouldn’t bother to test because they’ll have to change the whole damn thing 5 minutes after they’re done, others claim testing is the only reason they were able to keep working. Here are some of my thoughts looking back.

Our Background

When we started, only two of us had a test-infected background out of the five technical guys, me being big on TDD. Two other developers never wrote tests before. We agreed that tests were important, but that’s about it. I set up a continuous integration server and with that we were off. With time, the habit of writing tests spread out among the team. Some are TDD passionate, some write tests after the fact, but we generally all believe that tests should be written extensively.

Not everything is worth testing

We’ve seen several quite rapid changes to our UI. Having less tests in this area makes sense. We rely on QA for making sure all buttons are displayed etc. To make this clear: we have no selenium-like tests for UI components but have tests for most logic being done by the UI. I think this is generally a good practice, since having to maintain selenium tests would be hard when you throw things around a lot and change flows. Some basic automated sanity tests pretty much does it.

Everyone learned to love tests

I love seeing other guys in the team delete a line of code to see which test breaks and understand why it’s there. Even more I love the frowning face when no tests break. This addiction to tests shows how much value the team’s getting out of having solid tests, hands down. No need to stress this further I believe.

Tests save our asses repeatedly

Having an extensive suite of tests allows us to make rapid changes to our code base, as is needed in most startups, and rely on the solid tests to tell us whether we’ve screwed something up. All the code that has anything whatsoever to do with sensitive and important information is heavily tested which is a huge bonus and a necessity in our line of business (personal finance protection).

TDD is just magical with complex algorithms

We have quite a few complex algorithms that require multiple entities and ideas to perform. I find that the parts we’re most satisfied with maintainability-wise are the heavily TDD-ed algorithms we’ve got. Being written with rigorous TDD gives us so many advantages:

• This critical code usually has a lot less defects.
• The code is a lot more readable, well decomposed and allows for easy changing once we find out a need for tweaking the algorithms.
• Working in TDD magically forces us to form our problem domain better, making us have a language of our own in talking about the problem. This happens less naturally in other forms of working on algorithms.

Summing our testing experiences

All in all, I think the whole team would agree that dedicating time to writing thorough tests is proving itself valuable and because of that people are writing more and more tests without any of us ever stopping and saying “we should write tests” (well, I swear I didn’t do it too much). It happens naturally when people get the value out of it. It’s fun seeing how today BillGuard has become a company that organically values testing so much I don’t even feel a great need to stress it to new people because they’ll quickly see there’s no real other way. We’re far from being the poster children of Clean Code, but I’ve got my fingers crossed.

If you’re interested in accomplishing the same at your work, you might find this recent post of mine of some help.

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

Pushing forward with the Autonomous Craftsmanship Core series. This week on our plate: How can you force pairing down the throat of your team even if they’re not really into it?

I’ve already touched on this subject a few times before, especially since it’s one I find really important and had to handle a few times before. Pair programming feels to me like the best technique currently known to the software industry for making a team highly productive and have global code ownership. It’s one of those things that didn’t click right away when reading Extreme Programming Explained, but man did I get it wrong.

I’ve loved pairing from the moment I started doing it and ever since I find it hard doing hard work without a pair by my side. The problem is that most of the software shops around are still not pairing regularly, making it hard for a pairing junky like me to have fun.

So, how can we stop bitching about our team not pairing and actually get shit done with a pair? As opposed to the previous posts on the Autonomous Craftsmanship Core, this is not something one can do alone, and so is a bit harder to work around.

Basically, not calling it pair programming. It might be a bit tricky socially, but it’s worth it. Some real examples:

Can you help me out?

If I have a short task (ideally – no more than 30-45 minutes) that I want some help with, I just find someone on my team and ask for some help. Hopefully, you’re not in a team where asking for help sounds problematic. Then, once you’re both on your computer and working on the problem – you’re pairing. That was easy, wasn’t it? Do it enough times (without looking like an idiot that always needs help) and your mates get acquainted to the idea fast.

Volunteer to help people

I love walking around the team and seeing what people are doing. Every once in a while, simply walking by someone and asking how are things going might trigger a “Take a look at this” response, and you can help a fellow coder get unstuck. I used to do this even outside of my team. Spending 15 minutes with someone to help him solve a problem and share some knowledge and technique in the meantime is just awesome.

Review code to be in the loop

I try and read most of the commits being done to projects I’m involved with. It has many advantages, and one of them is that I’m familiar with most of what’s going on around me. That means I might find little problems, ideas and changes that might help my team. I then just go to the person that made the changes and share my ideas. Sometimes that would drag us both into a short pairing session.

These are basic techniques that I’ve found helpful several times. Even people that have never heard about pairing start liking it (if they really find you helpful and not annoying, of course). I just love seeing how after a few weeks, people come and ask for help if you’re not around, and how slowly the idea of doing some tasks together becomes obvious. I don’t have to have them call it pairing, and it doesn’t have to be 100% of the time. The bottom line is that good practices stick, even unconsciously.

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

Continuing on the thread of the Autonomous Craftsmanship Core, we reach another problem: “they” just won’t let you use the right tool, or in the right way. As I’ve said in the previous posts if anything is so bad you can’t work with it – leave; otherwise, you gotta learn how to make do.

A pragmatic programmer uses the right tool for the job. We all know that if you have a hammer, every problem looks like a nail. In this post I’m talking about the situation where you have an awesome toolbox right there and yet they’re forcing you to unscrew something with your pinky’s nail. Excruciating to your brain.

The thing is, a lot of the times you can just use the right tools and the hell with everyone else. Yes, you can’t just write code in whatever programming language you want, but in a lot of other situations, you can do what you want to. I think this is best shown with a few examples:

“Don’t commit too much. Say once a day”

That’s a real quote a friend’s boss told him. Turns out committing multiple times a day is too messy. Most programmers might just sulk and do as they’re told, but with today’s technology you’re no longer bound to these stupid rules. Your team uses subversion? So what! You can use Git locally, do whatever you like, and just push once a day everything via git-svn. Same solutions are available for just about any VCS combination you can think of! I’ve done this several times working on projects with a VCS I didn’t want to mess with.

“We can’t have a CI server”

Why would someone be against that? Maybe your company doesn’t want to allocate a new server for such a “useless” thing, or maybe the system admins don’t have time for your little “developer toys.” Lucky for everyone, it’s no longer the case that you need complex setup for such stuff. It’s just a matter of looking around. For example, if you’re doing open source you just need to give Travis a look and see you’re suddenly all set. On the other hand if you’re code isn’t open sourced setting up a local Jenkins server is so so easy. You just double click a file and you’ve got it running. If your build isn’t too CPU hogging, you can run it on your box! And I’m almost certain you can find some server with some spare cycles to install it on.

Autonomous Craftsmen Make Do

That sums it up. A craftsman’s gotta do what a craftsman’s gotta do.

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

My first team had (among many other great attributes) the custom of strictly following a style guide. It was followed so religiously, I’ve yet to come across another place that does so to the same extent. It wasn’t really written down anywhere, but after a couple of weeks of pairing with the other guys you got it.

What does that mean exactly? It means that we wrote code that looked, to a large extent, like it was written like the same guy. We put 2 blank lines between regions. Members had a specific way of documenting. We even used the same idioms for creating empty lists etc. (Java).

If we paired with someone and saw him indent the code the wrong way, we’d go all OCD until it was fixed. And it was regarded totally OK. We didn’t feel like we were nitpicking on each other. It was the way things got done. I even know a guy that would notice extra whitespace at the end of lines (without any IDE help).

Ever since, whenever I see code written with careless indentation and whitespace I feel like the coder who wrote that just doesn’t care enough for the craft. Yes, No Whitespace – No Care!

What’s the big deal?

If code isn’t written in a consistent style in your team, whenever you come across code with the spacing a bit wrong, the first thing your head’s going to process is “I didn’t write this.” This is a natural feeling, and as we all know coders have a hard to restrain impulse to rewrite any piece of code they didn’t write. Once all the code looks the same, that feeling isn’t that hard and you can actually focus on the code itself and have a better sense of ownership. I know, it sounds stupid, but that’s the way our stupid minds work in.

A big part of the Extreme Programming principle Collective Code Ownership is obtained by simply keeping a consistent style. Anything important enough to become a core value of the only methodology that works must be worth the effort to take notice of.

The next time you see code with reckless spacing, change it and let your teammates know. It might be hard at first but the end goal is important – the ability to fluidly read code, without feeling like you’re wearing someone else’s shoes.

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