Interview with Adam Cogan (cont.)
So what does the Auditor do, exactly?
Well, Code Auditor essentially is a little bit like FxCop. FxCop works well. What it does is, it analyzes the assemblies but it doesn't analyze the actual code that the developer writes. So Code Auditor actually analyses the source code of any project that has text files.
Richard Campbell: And then how many rules are you talking about for your code?
Adam Cogan: I think it has about 170 rules.
Richard Campbell: Wow! And obviously you can turn these on and off and add your own, that kind of thing?
Adam Cogan: Yeah you turn them off if you don't agree with them or-but if you don't agree with the entire rule, if you've got an exception for that particular rule in that piece of code then you comment and the Code Auditor will skip reporting the exception on that piece of code.
Carl Franklin: You know I am just looking through some of the rules on your page and we will link to them. Just a single rule might be a really big deal. Like, check this out. I don't know how to say it any better: Number 13: To use XP wisely. It says,
"Extreme programming is a big concept which we try to use here. I don't adhere to every idea, but there are some very practical rules I follow which improves the way we develop large projects:
And then, you have a link to rules to better unit tests. So that's pretty awesome, I mean its just like one little thing, that one little rule that covers three tips for using extreme programming. A couple others here; Can you make a setup exe in one step? And then you have what is essentially an article on how to create a good setup.exe. So it's not just like a tip or a rule. Some of these are fairly in-depth.
Never set a deadline more than three weeks from the previous deadline. Deliverables become a lot easier to manage and meet when they are small.
All production code is done in pairs. Too expensive, some people say, and yes, its pricey, but its better quality.
Write tests before you write code. Unit tests become a way of life and are again, expensive at the beginning but pay off during the course of the project."
Adam Cogan: So I might delve into just a couple of those that you just mentioned Carl.
Carl Franklin: Okay.
Adam Cogan: [In] every project that we do, some are very large and some are quite small. Essentially it must be broken down into what we call release plans. A release plan is, by default, try[ing] to fit in as many tasks as [we] can into 160 hours. So that's typically two guys, two weeks. The maximum that we can do is three weeks. We don't allow any bigger than that. One of the most important things about dealing with clients is typically about communication and being visible. So, we try to make the releases as quickly as [we] can which is a couple of weeks, and at least that way its also repeatable whether it's a big project or a small project-they are still the same size. So, if we can't fit it in, we make another public folder and we break the task down, we move it into that. And the good about it is, basically the customer's e-mails us tasks or changes or bugs and you just drag it into the appropriate release and then you reply, "done" with what you did, like the new screen capture or whatever; and at the end of two weeks they actually get to test that code. So, even if I don't see a new version for a couple of weeks, they at least see-[we] were fairly visible in showing what's being done and I think that's a great way to work when you are working with clients.
Carl Franklin: It's just an incredible depth of knowledge and experience in these rules. That's just amazing.
Adam Cogan: And just talking about the XP wisely, the second point there about pairs. We deviate slightly from extreme programming, where they do everything in pairs on the one computer. Everything here is done in pairs but they all have their own computers and essentially what we do is we try to make them sit close together. And I can tell you that I feel like I get all the benefits of what pairing does, which essentially is when you are stuck you get help. I will tell you when I walk around the office here, and I will see one of the guys often leaning over, looking at the other guy's screen when he sees a bug. So, when they are sitting very close together, they will naturally just lean over, help that guy get past his bug, and then he goes back to his own thing and they are both working on the same release.
Carl Franklin: Yeah I remember working in an environment where everybody had their own office and the developers don't bug each other and often you could spin your wheels for a long time. This is, of course, even before Google and Yahoo and anything like that, before there were any resources. So, I remember that being very challenging.
Adam Cogan: Yeah.
Richard Campbell: And I think the main issue is to resist thrashing, right? It's that wasted time of you trying to figure out a problem and going around in circles over and over again. As long as there are always two people working on a given problem, thrashing is almost impossible. You just don't get there.
Adam Cogan: And that third point you just brought up about the unit testing. It's fairly important for me because often the developers hear, "oh how many unit tests should I write-I should aim for 100% code coverage." Well, as far as I am concerned, 100% code coverage is 100% impractical. And so, I only essentially allow them to write unit tests for a series of things: Dependencies, when there are external dependencies, DLLs, Web services etc., any fragile type of code like regular expressions must have a unit test. You can't add a regular expression into your code without a couple of unit tests covering it, and when you've got calculations. There are also a few other cases where you are allowed to write unit tests which has basically to do with flow forms and other things.
You can read more about these rules at http://shrinkster.com/cal. This conversation continues online at http://shrinkster.com/cak.