via .NET Rocks!

• "My point of view is that legacy code is just code without tests."
• "What's important is to try to imagine something that is just a bit better than what you have currently. If you can target those things, then over time you will really start to make a difference in the code base."
• [in order to reduce fear of a legacy codebase perform a scratch refactoring...] "Check out the code with no intent of checking it back in. Refactor different sections... enough to get a feel for the code base, to get a handle on it..."
• "Functional languages get us away from some of the issues that have become so problematic in testing... Functional programming reduces the number of side effects of code..."
• "C# is getting too big. Every time you turn around there's been something added to the language. I'd hate to see it end up like C++."
• [regarding the new raft of languages] It's a bit like the tower of babel. For so long we had a mono culture in the industry around java and visual basic. Now it's at the point where everyone and their brother is designing a new language."
• [Regarding OO languages hitting a wall] "I think there is something to that, but I also think it has to do more with the type systems."
• "There are two basic themes of type safety... Type inference and Laziness, create data structures and apply limitations after the fact. I recommend that people learn Haskell. It really throws your mind in strange directions."
• [Regarding OO programs becoming legacy...] "It seems to be the fate of everything... Progress happens."
• "The history of the next 30 years will be about mining the last 30 years"
• "The thing about learning Haskel... it's great... You just need to learn to think like a martian!"
• "When you're choosing the right tests for something you have to think about it very deeply. you have to understand exactly how it operates... as you go through that process you'll arrive at higher quality without necessarily putting the bugs in there in the first place. So TDD and unit testing in general gives us quality, not through just test failures, but by forcing us to think through our code deeper than we would otherwise."
• [Regarding Agile] "The only thing that gets me is that there seems to be a moratorium on design in the industry over the past 10 years. There was a time when peopled talked about the intricacies of object oriented design... Once you go ahead and say 'Design is going to emerge' people say 'oh well then, we don't have to talk about that'"
• [Regarding the question: has architecture been forgotten"] "I think to a degree... there are some not nice things that have happened with the nominal title of architect over the past 20 years. But architecture expertise is definitely necessary in many application domains but they have to have a real view into the code."
• "Architecture knowledge has to be in the team... It's a very communicative role."
• "The import thing is continuity of knowledge in the team... When you have that, everything works out well... When you don't, everything is a fishing expedition when you need to make changes.
• "Documentation is important but you don't want to get into the situation where everything is exquisitely detailed and has to be changed every time you change the code. It gets crazy."
• "If you see code that is crazy and odd and you understand Conway's law, it really says something about the team that produced it. If you need to produce code in a team effort, than that team needs to get along together in order to produce good code. Otherwise, they are just sabotaging each other... even if only subtly."
• Emergent design can work very well, but in large organizations with a large codebase you have teams that do a little work on some code and move on, a little work on other code and move on. With agile, the original goal was to have collective code ownership. In large organizations there is no ownership so you have an odd tragedy of the commons. In large organizations, there needs to be a notion of ownership and if you don't, you shouldn't be surprised with what you get."

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can't run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.