Chris Johnston

Siva Jagadeesan has posted an interesting article titled, “Fresher and Experienced Developers – Friends or Enemies ?” In the article he lists some of the advantages and problems of pairing freshers with experienced devs. He touches on many of the problems I have with pairing and does a much better job expressing some of my frustrations then I did.

I think I fall somewhere in between a fresher and an experienced developer, but I can definitely relate to all the problems listed. It is amazing how your morale suffers after 5 days watching someone else code cause you don’t know enough to contribute.

I have a problem with the solutions Siva gives though because they all seem to be aimed at the fresher. It takes two to have a problem and as such would like to offer up some advice to the experienced dev:

1. Be patient and allow your pair to make mistakes to the point where they get themselves in trouble. We learn best from our mistakes.
2. Even if your pair is moving slowly, stay focused on the task at hand. I really hate when I start driving and my pair immediately starts doing something on his notebook computer.
3. Ask for and accept feedback from your pair, you are not always right regardless of how experienced you are.
4. Pairing is about more then just finishing a given story card, make sure you also teach. And teach more then just the task at hand, make sure you also teach the overall context.
5. Accept the possibility that your pair may know more then you in some area and be prepared to learn from them
6. Do not just jump all over the code base, wildly scrolling through pages. Slow down and explain what you are doing and what you are looking for.

Also, one thing I think we miss is that fresher is both someone new to programming, e.g., someone just out of university, but also to someone new to the code base.

I realize this is clearly stated on the Mockito website, but it caught myself and my pair up for a little while. we were trying to stub out a ResourceBundle using Mockito and found that the unit test kept trying to find a concrete implementation of the ResourceBundle. The reason, we figured out is that the ResourceBundle.getString() method is final and Mockito cannot mock or stub final methods. Something to keep in mind when working with this mocking framework.

It has been quite a while since my last post. Mostly that is because I have been fairly busy with a new project and busy trying to get my sorry butt into shape (it is amazing how much time exercising can take up). Anyway, the new project uses C# 3.0 and .NET 3.5, ASP.NET MVC and jQuery. All three are new to me and I have to say that I really like all three.

C# 3.0 is a really nice language. It seems to have gotten generics correct making for some really nice code, especially were the database layer is concerned. We are using LINQ to SQL and we have been able to implement a single class for the repository which works with whatever model object type we give it. I also really like the inclusion of Lambdas and delegates, which make for some very clean code constructs and are much cleaner then anonymous methods in Java.

The second new technology to me is ASP.NET MVC. This allows us to do ASP.NET without actually using ASP.NET. Currently, it is still in preview releases, but it is definitely heading in the right direction. Everything (with the possible exception of views) is completely and easily testable. This means no more having to hide functionality behind presenters or controllers and hoping it works in the code behind. Controllers are completely testable right down to testing what views or redirects they return.

The last new thing I am using is jQuery. I fully understand why it is becoming the defacto Javascript library. To do most things only require a few lines of jQuery Javascript and its AJAX and JSON capabilities are incredible. One nice thing about ASP.NET MVC is that it is capable of returning JSON results with a single line of code. This makes working with jQuery seamless.

If you are starting a new .NET web project, definitely check out ASP.NET MVC, C# 3.0 and jQuery. If you are new to C# 3.0 then check out the book C# in Depth. It highlights all the changes since 1.1 in a nice concise format that will bring you up to speed quickly.

If you are starting to work with Git, then have a read through this excellent introductory walk-through.

The idea of Two-Pizza Teams has been around for a few years, but I just saw it a couple of days ago. I think it is the best term I have seen describing the optimal software development team size. The idea is that your team should contain no more people than can be fed by two pizzas. To give this a figure, a team of 5 – 10 people is perfect.

The idea behind this is that you shave off small problems and give them to small teams to solve. The team is completely autonomy and owns both the problem and the solution. This allows the team to innovate and create the best possible solution. In addition, since the team is so small, communication is fast and everyone stays on the same page throughout the project.

I think there are a few other advantages to having small teams which are:

• There is nowhere for anyone to hide. It is easy to recognize the dead wood and build small, efficient teams of highly skilled people
• There is no space for specialization. Everyone on the team has to become proficient in every area within their discipline and beyond. A specialization represents a possible bottleneck, so everyone has to learn how to do all the different jobs. For example, you wouldn’t want a dedicated DBA so all the devs needs learn how to work with the database. The result is poly-skilled workers who are able to move from team to team and from technology to technology and have richer tool sets with which to solve problems.

The best anecdote I have heard comes from IBM. Apparently, there were two teams at IBM both of which were trying to develop the same software. One was large and the other small. The software was non-trivial, something like an operating system. Software that you would expect a large to team to have to handle. In the end, the large team was over budget, over time and did not meet all the requirements while the small team met everyone of their milestones and their version contained all the features. (I believe this is properly documented in The Mythical Man-Month)

In reading about this idea, I came across several blogs that basically said there are some problems that must be solved by large teams. I think the above example proves this wrong.

One last thought about this is that teams should always have an odd number of people on them. This way, there is always someone to break the tie.

Other links:

• 37Signals – 3 people for version 1
• 37Signals – If you’re working in a big group, you’re fighting human nature
• FastCompany – Inside the Mind of Jeff Bezos
• Paul Graham – You Weren’t Meant to Have a Boss

Jim Weirich gave a brilliant presentation called Shaving with Ockham this year at MountainWest RubyConf 2008. His premise was K.I.S.S – Keep it Simple Stupid. The presentation is both entertaining and educational. And at the very least, it servers as an excellent introduction to LISP.

Weirich takes the audience for a walk through the various programing languages that he has used over his career. These include LISP, FORTH, Erlang, and something resembling Java/JSP. He then extracts a few simple rules from each of the first three languages that make them simple and very powerful. These elements are a small core, simple rules, and powerful abstractions.

Along with showing simplicity, Weirich also analyzes why programmers make complicated, complex programs. He suggests that it because we like to solve complicated, complex problems with complex solutions. We get so intent on solving a problem that we do not look around to see if there is a simple solution.

The presentation ends with Ockham’s razor: “entia non sunt multiplicanda praeter necessitatem”, or “entities should not be multiplied beyond necessity”. Also known as, “all other things being equal, the simplest solution is the best”. This is definitely a video that every programmer should watch.

The last project I was on, I attempted to be very disciplined and do test-driven development all the time. This didn’t also work out. Far too often I found myself writing code for which I hadn’t written tests first for. I would have to stop myself and write a test first. Similar to driving, the tests acted as speed bumps preventing me from going to fast.

Most of the time, writing tests was fine. They forced me to think about what I was doing. Instead of creating single, long methods that did more then one thing, the tests forced me to create small, single purpose methods. This resulted in cleaner code that was easier to test and easier to work with. And it also resulted in a much clearer understanding of the solution that I creating.

However, there were times when I knew exactly what I wanted to code and how to code it. This is where the speed bumps came in. Instead of just forging ahead and programming, I had to stop and create tests. And I must admit, far to often, I coded my solution first and created tests after. And far too often, I had to recode what I had done because it wasn’t testable. So the speed bumps, although frustrating at times, in the end proved to be the better way to code.