fuzzylizard

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.

I have been thinking about Two-Pizza Teams and some of the potential pitfalls companies might fall into implementing this idea. And I think I have found one based on the last project I was on.

The last client I worked with had a factory style, compartmentalized view of software. They spent months working on the design and when they thought they had it right, they sliced it up into small components and farmed them out to the lowest bidder. When it came time to integrate those pieces back together, they were stunned when they didn’t fit and the application refused to run. Six teams then spent months fixing everything up to release a very fragile, but working, product.

Part of the problem was that they tried to implement and solve too much too quickly (well, in combination with the whole lowest bidder thing). The final application basically implemented the same thing four times. Instead of solving the problem for one product line and implementing a working, stable solution then moving on to the next product line, they did all four at once.

Moving this idea forward to two-pizza teams, I have a fear that companies could do the same thing. One trick to making small teams work is how you divide the problem. Each team, and thus each problem, needs to be completely atomic. Therefore, no two teams are implementing the same ideas.

If you have an application that does basically the same thing across multiple product lines, have a single team do the initial vertical implementation (i.e., end to end across all integration points). Once the initial implementation is completed and working, other teams can then build upon it sequentially, implementing the remaining product lines upon a proven solution. This will also provide business value back to the company earlier rather then later and give the user’s something to test.

I think the best way of dealing with this is to be constantly breaking up teams and not letting any team work on more then one problem together. As soon as a team has solved their problem, that team is disbanded and the team members move on to new groups. This way, you maximize knowledge sharing and allow everyone to learn about what that team did.

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

As part of a larger project, I am starting a new open source Github project - Studio Gallery. It is a Ruby on Rails application aimed at professional photographers.

The app will allow photographers to create galleries for clients, uploading photos from photo shoots. Once the gallery is created, clients can log on and select the photos they want to order. Other features include the ability to rate photos and filter by ratings as well as pick the size of print to be ordered.

The project is just beginning, so nothing exists for it yet except the Github repository. I will putting up a Trac site or Wiki for it soon.

I have been attempting to get CruiseControl.rb 1.3 running on my new Mac with little success and am wondering if other people have been having the same problems. I have two Macs that I am trying this on and neither is working. Both show the same error.

I am able to start CC.rb using ./cruise start and am able to add a project. The problem is when CC.rb goes to do the first build. I keep getting the following error:

BuilderError: svn: PROPFIND request failed on '/svn/trunk/project_name'

If I expand that, the actual problem is with the following:

svn --non-interactive log --limit 1 --revision HEAD:1 --verbose --xml

The important part is the --non-interactive switch. If I remove that and run the command directly from the directory where the project is checked out to, it works fine. I include --non-interactive and it fails.

Both machines use default versions of svn (i.e., whatever came with the computer).

My theory is that the problem lies with OS X’s Keychain program, which is where the credentials are stored for the svn repository. In interactive mode, when svn asks for the username and password, keychain steps in and supplies them. However, in non-interactive mode, these credentials are never supplied because they are not cached properly by Subversion.

My problem is that I am not sure how to test or resolve this. I am somewhat reluctant to install Subversion over top of the currently installed version because I am not sure what I may screw up. However, I am going to continue to investigate this and see if I can’t figure it out.

Has anyone else had this problem and, if so, how did you fix it?

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.

Google has announced the preview release of the Google App Engine. It allows developers to build web applications and run them on Google’s infrastructure. Currently the only language that is supported is Python. The service is free, but limited to “500MB of persistent storage and enough bandwidth and CPU for 5 million monthly page views”. Google is also limiting registration to the first 10,000 developers who sign up.

The development environment includes the following features:

• Dynamic webserving, with full support of common web technologies
• Persistent storage (powered by Bigtable and GFS with queries, sorting, and transactions)
• Automatic scaling and load balancing
• Google APIs for authenticating users and sending email
• Fully featured local development environment

It will be interesting to follow the development of this. Hopefully Google will support more languages when this goes live (Ruby and Java would be really nice). At a minimum, this might just give Python the boost that it needs.