I am the host of “.NET Rocks!”, an Internet audio talk show for .NET developers online at www.dotnetrocks.com and msdn.microsoft.com/dotnetrocks. My co-host Richard Campbell and I interview the movers and shakers in the .NET community. We now have over 170 shows archived online, and we publish a new show every Monday morning. For more history of the show check out the May/June 2004 issue of CoDe Magazine, in which the first column appeared.

In Show #160 we spoke with Adam Cogan. Adam is the Chief Architect at SSW, a Microsoft Certified Partner specializing in Visual Studio .NET 2005, Windows and Web, SQL Server, OLAP and RS applications. At SSW, Adam has been developing custom solutions for businesses across a range of industries such as government, banking, insurance, and manufacturing since 1990 for clients such as Microsoft, Quicken, and the Fisheries Research and Development Corporation. We spoke about a large series of rules that he has published for software development, as well as general technology use.

Carl Franklin: [One] thing we are going to talk about this hour is your rules for software development. You have come up with a whole series of best practices that you have your guys use, and also have extended out to the community and even built some software around that.

Adam Cogan: Yeah. Essentially my interest revolves a lot around efficiency and I express and implement them through standards and rules. And I guess I am after consistent outcomes and a consistent experience and quality. And so it’s been a fair bit of time, implementing rules and just coming up with new standards.

Carl Franklin: How did this project start?

Adam Cogan: I don’t know really how it started. It kind of started in the very beginning it’s….

Richard Campbell: I know. I am going to reveal a secret about Adam. I don’t know if he necessarily wants it out but I know exactly where this has come from. What most people do not know about Adam is his history. Before he was a geek, what did the boy do for a living? Are you going to tell them?

Adam Cogan: Oh! I was in the army. I was an accountant.

Richard Campbell: Here you go. Not only that but a tax accountant if I remember correctly.

Adam Cogan: That’s right. So I am not sure if I put it down to being an accountant, or being in the army, but I certainly became disciplined. I moved out of the accounting field because it’s not real easy to [impress] chicks when you tell them you are an accountant and back then, geeks didn’t have-I think geeks these days have a even worse reputation. At least the accountants go home and don’t do any work.

Carl Franklin: So in other words, you do have an anal-retentive streak, Richard is saying.

Adam Cogan: I think so. We created a series of Word documents and we put all the rules of how we were going to work. There was not too much technology back then and the rules we had were for dBASE and for Fox. Today they basically cover everything from exactly how to use e-mail and how to use Instant Messenger and how to set up your SQL Server or how you implement exception logging into your application.

Carl Franklin: And I even like the UI rules that you have; you know, about margins and buttons and fonts and things like that.

Richard Campbell: And then naming conventions. All these things are valuable. I find interesting when I read this. You send all your employees here. This is like a handbook for working at SSW.

Adam Cogan: Yeah. We actually have a lot of internal rules as well, but anything that we can, we make public. There are essentially a lot of ways to do the exact same thing. If I ask a developer to show a set of records on a form, I don’t know whether he is going to use the DataGrid or Repeater, or he is going to use datasets or objects or embedded SQL or stored procs or binding in the designer, or if he is going to bind in code. There are just so many choices that I don’t want him to have to make. I just want him to do the same standard thing every time. I don’t want him to name the projects in his app differently. I don’t want to hear it called engine, I want it to be called business. I don’t want to go through the argument on every project: are we going to use datasets or are we are going to use business objects? I want to say [that] by default we are using datasets unless there is an exception. So, I basically am reducing the choices of those types of arbitrary things.

Richard Campbell: So it seems to me, as time has gone by, you have just sort of rounded up more and more of the thinking around these issues and put them all in one place. I mean, it’s quite a gambit of things on your rules page.

Adam Cogan: Yes. This has many advantages and many disadvantages I guess. Like one of the biggest advantages it has is, we have a very simple induction process. When someone new joins our company, basically we have them up and running on large projects on the fourth day because we have the induction process which takes the first three days and during those days they learn exactly how to configure their PC with all the tools that we use and they learn how to estimate jobs and how they are going to speak to customers, exactly the way everybody else does. And when I say this induction process, I am not talking about reallocating another guy to act as a trainer. What they do is, they get their PC, they have got Web access, and they read all these rules and they complete a series of these small exercises, which confirms that they understand all the important pieces.

Richard Campbell: It’s basically an exam?

Adam Cogan: I would call it an exercise.

Richard Campbell: Okay. You just want evidence that they have read and understood what you have asked them to read?

Adam Cogan: Correct.

Carl Franklin: What is the vastness? What’s the scope? How many of these rules do you have in this list?

Adam Cogan: Oh, I have never counted them to be honest. But there [are] 51 pages of public rules and each one of those possibly has about 50 each. So we are talking in thousands. There are a lot of internal ones as well; and obviously that number of rules has a downside.

Carl Franklin: Right, discoverability, yeah.

Adam Cogan: Yeah. So essentially, there are many that are quite important and then there are many that are less important. We have rules [concerning the use of] curly braces. We [have] already had all the arguments on whether we have the curly braces on the new line or the same line. I am not going to have those arguments any more. We make a consensus, do a little bit of investigation, we make a decision, and that’s the way it goes.

Carl Franklin: It’s good.

Adam Cogan: We have a lot of other things that are probably less important that you know that consume time. With Windows Forms, Microsoft actually has a guideline which [defines] the exact size of a button. Now, most developers don’t bother with it. They randomly choose all these things. But I don’t want it done that way. I don’t want any time wasted on it. So I needed a way to automatically check these projects.

Carl Franklin: Yes, so how do you do that? I mean, how do you go through 5000 rules by looking at-that’s a lot of time wasted?

Adam Cogan: Well, essentially what I tried to do was automate as much of this code quality as I could. Just like the e-mail tool we developed. We then developed [a] tool to support these processes. So, we developed this tool called SSW Code Auditor, and it essentially uses the power of Regular Expressions. Every developer has to run this over before issuing their test which we call a test place. It must be Code Auditor compliant and FxCop compliant and we have another tool called SQL Auditor, which checks SQL Server.

Carl Franklin: Excellent. And so, is this a sort of thing that runs automatically when you compile?

Adam Cogan: It’s integrated into Visual Studio or you can run it [from the] Command Line or you can just use the GUI.

Richard Campbell: So what does the Auditor do, exactly?

Adam Cogan: 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:

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.”

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.

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