I’m working on this theory that the more automation you wrap around a development environment - testing, static analysis, etc. - the lazier the developers in that environment get due to increased reliance on the automation.

That’s not necessarily a bad thing, but I’m not so sure it’s good, either.

Let’s say you have a .NET project and you’ve got it totally wired up with automation.

• You have a continuous integration server running the build on every check-in.
• You’re running unit tests and failing the build if the test coverage levels fall below a certain limit.
• FxCop runs with almost all the rules turned on to check for consistent behavior.
• StyleCop runs with almost all the rules turned on to ensure the code is consistently formatted.
• NDepend runs to check your dependencies and ensure other custom project-specific standards are met.

You even run your code through code reviews to ensure you get a second (or third, or fourth) set of eyes on everything. (No, that’s not automated.)

The point is, you’ve got all of these checks and balances in place so, ideally, the automation will catch a lot of the stuff before it even makes it to code review.

Somehow, though, you still see things creeping through. Things that should have been caught somewhere along the way. Things that don’t make sense.

Maybe it’s a bad naming convention that’s started that encourages the breaking of the Single Responsibility Principle… like HtmlHelper. (If you have to name your class with “Helper” or “Utility,” I’ll also put good money down that you don’t really know what it’s supposed to do and that you’ve totally broken SRP. But even if you disagree with my example, stick with me.)

So you add some automation around that to try and head off that bad naming convention. The build will break or give a warning or something if the bad convention is used. You educate the team on why the rules were updated and folks agree to amend behavior. Fixed, right?

Nope. There’s always a way to game the system. Now there’s a new convention where instead of “Helper” or “Utility” it’s “Service” but the point is the same - it’s a dumping ground for random, only loosely related functionality. But now everyone thinks it’s OK, it’s not a problem. Why is that?

The automation didn’t catch it, so it must not be a problem.

The automation only catches the exact rule being broken, but can’t enforce the principle. If a person doesn’t catch it - you, the developer - that doesn’t mean it isn’t an issue.

Another example: You have your test coverage requirement cranked up to 95%. That’s pretty high. It’s not 100% because in some cases that’s not even possible, but 95% gives you some wiggle room to leave things uncovered but have full coverage on those things you are able to cover.

The thing is, once you have a significant codebase, that 5% can potentially be pretty big. It might be several [small but important] classes.

How come there aren’t any unit tests for this code? “Well, the build didn’t fail, so isn’t it OK?” No, it’s not OK to not test your code just because you found a loophole in the automated rules. I mean, the cops may not have caught you for robbing the bank, but does it mean you didn’t break the law?

The automation didn’t catch it, so it must not be a problem.

The thing is, there’s not even always a way to catch this in code review. The naming convention thing can be caught… if the reviewer is familiar with the team’s past history and why the convention is in place. The coverage is actually harder to catch, especially if there is a lot to review all at once. You have to have a lot of discipline to mentally follow through the various execution paths and see how the tests exercise it. You also have to trust that the developer submitting the code for review did their due diligence and actually wrote the tests.

Missing it in code review can sometimes even mean worse things. Now, not only did the automation let it slide, but a fellow developer also missed it. Must mean you never have to fix it if someone else runs across it and does catch it, right? Why do you have this 3000 line method? “It made it through code review.”

Sometimes this means you update the automation to try to catch these things. Cool, now you can’t have a 3000 line method. But that 2999 line method is just fine because the automation didn’t catch it.

That’s why I’m starting to think automation makes you lazy. You can rely on the automation to catch so much, you stop trying to preemptively catch it yourself. You stop using your own heuristics to detect issues with your code and you fall back on the automation. And that’s sort of the point of automation - to help you catch things you’d otherwise miss… but it doesn’t entirely remove your responsibility for being the developer.

Be a professional developer. Use the automation, but also use your brain. Work with the automation. Understand that the automation around your build is a tool there to help you, not robotic police trying to enforce the law. Collaborate with your team and ask questions if you don’t know. Be amenable to refactoring - or rewriting - if something gets discovered after the fact.

Don’t let the automation make you lazy.

We were down quite a bit this year, back into the range we were at in 2006 - 2007. Again, it was a school night, but Halloween being on a Monday, we weren’t coming off a weekend (like last year when Halloween was a Sunday). It’s looking like when Halloween is in the middle of the week, we get a dip in visitors. Last year I mentioned I thought we’d be down this year and I was right.

Cumulative data:

</tr> </thead> </table> We shut down at 8:00p this year rather than running until 8:30p for a couple of reasons: 1. The visitor count was really dwindling. The majority of the kids in that last half-hour block showed up closer to 7:30p than 8:00p. 2. Phoenix needed to go to bed. She goes to bed around 8:00p and if we have people ringing the doorbell and knocking, she'd never get to sleep. The costume this year was The Mad Hatter. Phoenix was Alice, and Jenn was The Queen of Hearts. [](https://picasaweb.google.com/lh/photo/n2JyqLsPmlyZQ0HikbDr8g?feat=embedwebsite) My biggest peeve this year was one I already mentioned last year: "If your kid can't walk and/or talk, they're not old enough to trick-or-treat." I actually declined putting candy in the bucket a parent waved in front of my face that was intended for a sub-two-year-old sleeping in the stroller. They already had four kids with them, and then this fifth bucket pops out. "Who's this for?" I asked. "It's for him," said the mother, pointing at the sleeping kid. "What? Is he really going to eat this? *Really?*" I held up a Snickers bar from the candy bowl. The mother stared at me with this guilty look on her face but remained silent. "Yeah, I didn't think so. Happy Halloween!" I put the Snickers bar back in the bowl and shut the door. I'm the Candy Nazi.

		Year
		2006	2007</th>	2008</th>	2009	2010	2011
Time Block	6:00p - 6:30p	52	5	14	17	19	31
	6:30p - 7:00p	59	45	71	51	77	80
	7:00p - 7:30p	35	39	82	72	76	53
	7:30p - 8:00p	16	25	45	82	48	25
	8:00p - 8:30p	0	21	25	21	39	0
	Total	162	139	237	243	259	189

I finally got a chance to crack open Battlefield 3 this weekend. I like it… to a point.

I’ve played through what I believe to be about half of the single-player campaign. The graphics and sound are really well done and the gameplay is reasonably engaging. I’m enjoying the story so far and the variety of missions is enough to keep me interested.

There are two things about the single-player missions that detract from my experience:

1. The lights are too light and the darks are too dark. When you’re in a daytime mission, the environment is extremely light, in some cases to a point where it feels like you’re missing details in things because it’s all whiteout. The night/dark missions are really dark, sometimes even making you tweak your video settings to turn up the brightness… which then kills you when you get back to daytime. It isn’t just me - my dad noticed the same thing in his setup. I’ve disabled all of the dynamic contrast and super-black settings and all that junk in my TV. The only thing I can think is that they are trying to simulate your eyes adjusting due to lights - you’re in the dark, some lights hit you and BAM you can’t see anything. However, it’s really frustrating because you end up always missing something, making the game harder than it needs to be.
2. It’s sometimes hard to figure out what you’re supposed to do. Sometimes they give you visual cues of who you’re supposed to follow or what buttons to push, sometimes they don’t. I’ve run off and totally gotten lost because I think I’m going the right way when I’m not.

I’ve also tried the co-op missions. Well, I’ve tried two of them. I’d have tried more, but my dad and I can’t get past the second one.

Aside: Neither my dad nor I are super players, but we can hold our own. We’ve beaten all but two of the “spec ops” missions in Modern Warfare 2 on the hardest level. I beat the single player campaigns of Modern Warfare 2, Operation Flashpoint: Dragon Rising, and Operation Flashpoint: Red River on the hardest level. My dad’s gone Prestige in Call of Duty multiplayer. We’re not winning any tournaments, but we’re not newbies, either.

The difficulty on the co-op missions is ridiculous. We played the first mission on Easy and barely survived. The second mission involves flying a helicopter and giving close air support to a ground team. We’d have succeeded on that if the helicopter wasn’t so damn hard to fly. I have an R/C helicopter but it has coaxial blades and no collective to mess with. Flying the helicopter in this game forces you to deal with full collective - roll, pitch, and yaw - and it’s far, far too easy to dump it on its side. Anyway, it’s hard enough to fly that we can’t even beat that one on Easy, which means we can’t unlock any more co-op missions (because you have to progress through them to unlock more).

Not that it makes much difference, since there appears to be only eight total co-op missions.

I thought, honestly, there’d be more in the way of co-op. The whole reason I got it was to play co-op with my dad since we thought there’d be some level of co-op campaign. Oh, well.

I have not tried the multiplayer part of the game. Not because it isn’t good or whatever, but because I’m pretty much done with free-for-all, plotless game types. “Team Deathmatch” has no point. There’s no real teamwork, it just means half the people aren’t out to kill you. “Capture the Flag” just goes back and forth and never gets anywhere. “Horde Mode” sorts of things where it’s just endless wave after wave of enemies isn’t interesting either. What’s the point? I really like co-op campaign sorts of things where there’s both teamwork and a mission.

Anyway, like I said, Battlefield 3 is decent… but I may sort of be done with the war-based FPS until someone can bring back co-op campaign. (Seriously waiting for Borderlands 2!)

I’ve got Visual Studio 2010, MVC3, and the latest tools update. I’m all patched up. But I’m seeing something weird.

I start out and I have a solution with a single C# class library in it.

I decide to add an MVC3 site to it, so I do File -> Add New Project. I select an MVC3 project.

I click OK, and I select an Empty web application.

When I click OK on this screen, I get an error “Cannot add the item because the item to add it to is not a solution folder or the solution.”

I click OK to dismiss the error and I see there’s a folder in the filesystem named the same as the project name I selected (like it started to put the project in there) but the folder is empty.

To work around this, you have to:

1. Add a second project to your solution so that the solution itself shows up in Solution Explorer.
2. Select the Solution node in Solution Explorer by clicking it once. It can’t be one of the projects. It has to be the solution.
3. Now do File -> Add New Project and go through the steps to add the Empty ASP.NET MVC3 web application and it will work.

I’m not sure what’s going on where the project template is somehow keyed to the solution, but there you go.

There’s been a lot of hoopla around NuGet and the whole .NET package management “thing.” There’s a lot of praise going around, and I think they’ve done a good job for what they’re doing.

That said, I have what I’m sure is going to be an unpopular opinion:

NuGet doesn’t help me.

It seems to me the primary benefits of NuGet are:

• Get third-party dependencies into new projects faster.
• Help you more easily update packages in your project.

That’s all well and good, butI think I’m not the target audience for this, and I think I may not be alone.

I don’t create a bunch of new projects. I work primarily in an established environment. We add new functionality to existing stuff. We refactor and fix and add features and clean up old code. We don’t create a bunch of new projects. When we do, there’s more ceremony than one person on the team deciding “File -> New Project.” How does that new project affect our installers? How does it change our deployment model? Was there any analysis done to see if there’s already a project in the system that overlaps what the intent of this new project is?

Since there aren’t a lot of projects created, there’s not a lot of need to hurry up and get new third-party dependencies in them.

Even if there were a ton of new projects, we have a central repository of third-party dependencies. That’s necessary because we have a lot of teams working on a lot of different projects and solutions that integrate and if we don’t keep ourselves unified on an agreed-upon dependency version, we have DLL Hell and Massive Assembly Redirect Configurations to maintain. Plus, there are legal issues with redistribution of libraries and licensing. Before you can update a dependency, did you check to see if the license changed? Did anyone do the cost/benefit analysis of taking that new dependency? Did someone try it in an isolated environment to see if it broke anything?

The point is, you can’t just right-click and update a dependency. Maybe a more accurate statement, then, is:

NuGet solves problems I don’t have.

I have other problems, sure, but NuGet isn’t helping me with those.

So when I see that really great projects likeAutoMapper have stopped offering a straight-up zip-file download and are making me jump through the hoops of creating a temporary location, futzing with the NuGet command line to “install a package” that I’ll never use, then manually peel the assemblies out of that and delete all the package junk…I’m disappointed. I know it’s free software, but that’s not terribly customer-friendly.

CORRECTION: There are zip files for AutoMapper, you just have to dig for them. I have come across other projects that don’t do zip downloads, though, and that’s sad.

There is still something to be said for distribution in a standard downloadable zip format. I mean, whatever happened to xcopy deployment? Does it always need to be more complex than that?

It also doesn’t help that the latest MVC templates all have NuGet built in. Now it’s not File -> New Project and go. It’s File -> New Project, delete packages.config, delete the packages folder, and go. And that’s in an “empty project.” Yay for additional steps!