For the most part, everyone agreed with all that was presented in the Comments chapter, but once we got to the Formatting part, the real discussions started. There were three points in particular that people disagreed on:

• How to indent the private and protected keywords
• How to indent continuation lines, i.e., when a line gets too long
• And finally, how to indent, or line up, hashes

You would think that by now this wouldn’t surprise me anymore. I know developers are passionate about their tools and the code that they craft with those tools, and this includes code formatting. What always surprises me is the speed at which developers want to quantify and codify what the formatting should be. I have seen teams waste hours discussing whether a method should be capped at 4 lines or 5 lines.

For me, this kind of discussion is useless and completely misses the point. Developers should be discussing what the code is telling them in terms of refactoring and not the legal length for a method should be. Discussions should revolve around method and variable names, delegation and decoration, and extracting or inlining variables, methods, and classes.

Thankfully, my team is incredible and the final decision regarding formatting was to allow each dev to determine the guidelines for themselves with the overriding principle being readability and clarity.

I am also finding it amazing how quickly the team is adapting to the ideas in “Clean Code” and applying them to the code they are creating. In just a few weeks good method and variable naming and making code readable have become major concerns and are quickly becoming a standard part of everyone’s pairing experience.

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.

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.

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

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.

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.

Being new to this kind of coding, I am wondering if anyone has any tips, tricks, or patterns. We are trying to avoid having a large (1000+ line) class filled with procedural, linear code. So we have a bunch of utility, finder and builder methods and classes. This has made something better, but I am wondering if we could do more.

On my current project, we have a few classes that are 1000s of lines of code in length with maybe one or two methods. These classes are very procedural and generally only have one unit test. (On the up side, they have about 80% code coverage) The powers that be have decided to scrap the current code and rewrite it. Under these circumstances, definitely agree with, and helped push, this decision. But this is a fairly extreme example.

Is this decision only faced in these extreme examples, or are there other legitimate reasons for rewriting code? In my experience, rewriting the code, if done properly (e.g., with refactoring and using TDD), would be faster and result in better results then refactoring.