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.

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.

Currently at work I am writing mapping code. Code that takes values from one anemic object model to another anemic object model to another anemic object model. Aside from the usual iteration code, most of the code is comprised of this.setSomething(other.getSomething());. Unfortunately, this code does not map one-to-one from one model to another.

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.

When you inherit code, how do you know when to spend time refactoring a particular class versus simply throwing that class out and rewriting it? How bad does a class, method, package, section of code have to be to warrant rewriting it?

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.