From Journeyman to Master

Hey, Agile programming was mentioned on Dilbert.

I’m sick of Collective Code Ownership. I’m sick of it not because it’s a bad practice. It reduces knowledge specialization. Everybody knows the majority of the code base. The project won’t just fold if the chief architect left. But it has been misused as an umbrella for incompetent developers. To apply this practice, Agile teams usually share one source control account (this, of course, is also because of pair programming and swapping). But when a bug happens, it’s really nice to know who made the change. It’s not that we want to finger pointing. We just want to know the business and technical reasons behind the change. That’s why we leave our names in the comment when checking in at my current project. We didn’t enforce this at my previous project. Things didn’t go out of control because we only had 6 developers. After I left the project, the remaining lead developer suggested leaving names in the comment. The one developer who everybody knew made the most mistakes totally freaked out. I guess that was enough to demonstrate how good an excuse CCO is for the incompetent ones.

Sometimes I do feel like finger pointing. Why? Because I’ve had enough! I don’t mean I’m perfect. I make mistakes too. But I don’t make mistakes EVERY SINGLE DAY! Most of my mistakes were made because I missed a test or I misunderstood the business requirement. Not because I wrote crap code! But thanks to Collective Code Ownership, people who can’t stand dumping more crap on an already pretty high pile of crap ended up cleaning up somebody else’s mess. It’s good for the project, I guess. It’s definitely not good for the mental health of the cleaners. So if you find I’ve gone psycho in a couple of weeks, this post explains why.

Recently there has been a heated discussion about the comparison between Ron Jeffries’s way of solving Sudoku with TDD and Peter Norvig’s solution. After reading all the comments, I have to say that it’s a stupid discussion. I have at least two reasons.

First, Sudoku is not the appropriate topic to base the comparison on. It’s the kind of problem that requires relatively complex algorithm but has well defined requirement. In this case, the requirement is: Solve the Sudoku. But if you ask the majority of business application developers what kind of requirement they get, the answer will most likely be something like “Make it work”, “I can tell you. But don’t expect the same answer six months from now.” or “Requirement? We are not sure”. That’s the challenge the main audiences of TDD are facing. Whoever says you don’t need TDD in this kind of situation must be either a genius or insane. No, let me rephrase that. They are just insane.

Second, Ron Jeffries’s example is terrible. He seems like the perfect guy to reference if you want to badmouth Agile and TDD. He made it sound as if TDD eliminates the need for upfront design. That’s not what we do! Brainstorm/design sessions happen a lot more often in an Agile team than in a traditional development team. TDD is there to insure that we don’t write unnecessary code and all the code we write are covered by tests. These tests are usually white box tests. We already know how we want to implement it. We just want to make sure it works and continues to work over time. There are, however, times when we have to write black box tests. That’s when we were given a chunk of legacy code that nobody knows how it’s supposed to work. We have no choice but to gather the up-to-date requirements, write test to demonstrate them and refactor/rewrite the legacy code to be readable and working.

That’s my take on this debate. Ron Jeffries is not a good representative of Agile. There are better guys out there.

Currently I’m reading the book Extreme Programming Explained: Embrace Change (2nd Edition). If you think it’s just the first edition with a little extra, you are as wrong as a failed unit test. Kent Beck pretty much rewrote the book. Some of the new ideas and practices are very close to what I observed through my own experience. Some of them are brand new to me. I’ll talk about one of them here and others later.

Shrinking Team

The idea is that you don’t keep everyone in the team 100% busy. Leave about 70% of one person’s time free. Then let the team work on improving its process until it doesn’t need that one person any more. The team keeps shrinking this way. Later on, if the team has more work than it can handle, merge two small teams together to form a new team.

Now, even Kent Beck himself admits that he’s never tried this in a real project. He just borrowed it from the Toyota Production System. I don’t see it working the exact way he described either. At least I don’t want to be the “extra” person on the team. No, I’m just kidding. That’s not what the practice is about. Keeping a team running full load is definitely a good thing. That’s exactly what happened for the last six months in our project. We are so busy implementing stories and fixing bugs that we don’t have time to think what we can do better. Sometimes we don’t even think about what we are doing. The end result is a lot of duplicate code. Code that hasn’t been thought through. But now it’s too late to change it and I’m not the person that could have made the change either. Let’s just hope things will get better after the first release.

This guy from ThoughtWorks has some great insights and techniques about unit testing in Rails. Read this article to find out how to divorce Rails unit tests from database and use mock instead. I’m glad to know I’m not the only one who thinks that Rails by default is way too database centric.

I did something nasty that slowed down our test suite by two minutes (out of eight minutes). That’s when Ted started calling me The Two Minutes Guy. The problem is the result of a series of mistakes I made. * I used a Factory based on HashMap instead of if-else despite the fact that the HashMap contains only two keys. * I put the Factory in the domain object that’s using it instead of creating a separate class. * I named the class which the Factory creates Strategy. In fact, it’s not a Strategy at all. * Because of mistake #2, I created a static block to initialize the HashMap in order to reduce the overhead. But later on I moved the initialization of the HashMap into the constructor. * Then I successfully slowed down our test suite by 25%.

The worst of all the evils is that I was not pairing with anybody!!! Starting from next Monday, I’m gonna be the pair programming/switching police of our team. The first criminal to catch is myself.

Personally, I think refactoring is one of the best things that ever happened in software development. Everybody who’s ever worked with me will know that I’m a huge fan of refactoring. I don’t like living with broken windows. Refactoring is my tool to fix them. Unfortunately, this tool sometimes becomes an excuse to break windows. People occasionally tend to write bad code because they think they can refactor it later. The idea is good. But a lot of the time the code won’t get refactored at all because project schedule becomes tight or the original author simply forget to do it. Then other people start using and extending it. The next thing you know, it becomes too late or too expensive to refactor. More than 1000 TODOs hanging around in our project is the living proof of that. So please don’t live with broken windows even if you own a glass shop.

Whenever you are trying to solve a problem, you should always come up with at least five different ways and pick the best one. This sounds very textbookish but is actually a very good practice in software design. It is a fact that a lot of the time everybody knows that option number x is the correct choice from the very beginning. But this practice often triggers quite a few interesting thoughts. Some make you think about the problem from a totally different angle. An angle from which you will never look at the problem before. It might be inappropriate for the problem you are trying to solve. But it could very possibly be perfect for some others.

Recently, there has been a couple of articles criticizing Agile methodology floating around on the internet. I’m sure there are same kind of stuff before. But I just noticed these two because I happen to read Joel’s blog.

Having worked on two Agile teams for the last four years, I have to say that it’s the best four years in my career life. I’ve been living in a perfect world where everybody is Agile. You can imagine how mad I was when some people dare to challenge my “religion”. I have to strike back! But before I could do that, there he is, Martin Fowler, my favourite Fowler in the whole world. In his most recent blog entry, he talks about Agile Imposition, which is a way more rational view on Agile. One of the things that I strongly agree with him is that Agile is people oriented. It adjusts the process to follow the human nature. It makes developers happy. The happier a developer is, the better he/she is.

Of course there will be problems. But most of the time these problems exist regardless of what process you are using. How many projects failed because of the methodologies? Both articles above mentioned the cancellation of Chrysler’s C3 project. C’mon, don’t you have to define failure before you say something failed? This is especially true in software development. C3 project went live, didn’t it? And how did the first waterfall project go? Nobody ever said Agile is a silver bullet except the people who are trying to make it look bad. But before you do that, try living as a developer in an Agile team for a couple of months, OK?

We should all thank Martin Fowler for standing out on this one. Go read his blog. He’s a way better writer than I am.

This was written at Vancouver airport on October 6. The posting was delayed due to the lack of internet access.