As is usually the case when you’re under pressure to push a new release of an app for a client, something goes horribly wrong.

What went wrong tonight is simple: my Server Core install was never updated to hyper-v RTM, but windows update did its job fine on one of the client VMs that also runs Server 2008. Suddenly, the whole server is down.

Second install on the core install and still failing. I wonder how I’m going to apologize profusely to my client tomorrow. Oh the joy.

[Update 03:22: License wasnt activated properly, trying yet another install…]

[Update 04:05: Need my bed. Trying an uninstall of the role, followed by an update with the .msu. If that works I’ll reinstall the Hyper-V role tomorrow]

[Update 04:13: Apparently uninstalling the role rebooted the machine which then updated itself on its won with the RTM version. Don’t know if I should cry or laugh. Reinstalling the role now (seeing as there’s one less boot as previously expected, I have a boot to spare)]

[Update 04:27: All back in order, machines are up. Lost 6 hours of my life, less than impressed.]

I've now finished my previous gig and the guys are busy chasing some recurring issues with the application. Because of its complex architecture, those issues are equally complex to understand and debug.

Most of the code in this application happens around things we cannot put under unit-tests, because they all rely on heavy integration: syncrhonization of data between tiers, integration with external RFID hardware and 3G modems, sqlce and its multiple connections issue, and other equally difficult things to debug without running the system with said external entities. As a result, our code coverage is very low, and while we do have fakes for most of those external entities, we have to think hard and strong about the value provided by tests relying on fakes, or we'd end up testing a fake implementation. Not very useful to say the least.

That made me think of some testing anti-patterns I see recurring a lot on various project, and I thought I'd highlight them. That will let me reevaluate my position in a year time, and I also know that some of the people still invovled in some of my projects are reading this blog, so it will serve as a constructive criticism for their next projects.

1. I'll paraphrase Chad Myers, code coverage is the new LOC/day. Code coverage doesn't ensure quality, and the percentage is just that, a number. It needs to be put into context of the project: some areas do not need unit tests because they don't provide value. If you chase 100% code coverage, you're on a wild goat chase and you should reevaluate your understanding of the value of code-coverage (beyond the marketing bullsh*t).
2. It is more important to have a code-base with low cyclomatic complexity and loose coupling than it is to have thousands of text. Evaluating code quality is not only about testing scenarios, it is also about maintainability, understandability, extensibility, etc. Use NDepend to understand where you need to refactor or rework part of the systems.
3. Finally, and more importantly, I see no value in spending time after your code is released to write unit tests for the sake of it. Because the code has already shipped, you should not do any refactorings to it (or you'd end up with changes that you'd need to re-deploy and re-test, in which case you'll have to ship again, it all becomes a virtuous circle). So you end-up putting code under tests without bringing much value at all (again, except for increasing code coverage, see 1). Unit testing is a tool *during development* that helps you shape your objects and functionality and refactor your code until you get a satisfying result. Writing code aftewards doesn't serve much purpose.

There you are. With the advances like BDD, the focus on unit tests and code coverage by management should hopefully die a much to be celebrated death, as the focus shifts to the real issue: shared knowledge and process, arriving at a common definition of the what and why, and let developers handle the how.

The nice people at VBUG just sent me the result of the evaluation forms, and I am very pleased with the result, as a vast majority seems to have enjoyed the talk.

A couple of points were raised by an apparently unimpressed attendee, and as those forms are anonymous I thought I would take the time to provide some feedback here.

The font size was too small to read from the back

The font had been set to quite a big font size, added with a very large DPI. I'm afraid the length of the room compared to the size of the projector made it very difficult to accommodate everyone. If anyone has suggestions to reach to more people while still managing to put 30 characters in the wideness of the screen, I'd be very interested. Any experience from using different fonts? Maybe high contrast with dark background? I'd be quite interested in learning a few new tricks to make it work better.

That said, there were spaces on the front row, and I did ask everyone to confirm my font size was alright with them. I should have indicated this was a strong hint for people to reshuffle based on their sight :)

Discover powerpoint, where are the diagrams?

This one is quite accurate, I do not have powerpoint slides as a rule: unless I have something very compelling to show in a diagram I don't see a point in showing one. I had a slide introduction for the previous version of the asp.net MVC talk I did at DNUG, but I find them distracting and get the audience passive. Especially as for MVC I would end up showing either a product roadmap (I don't think it's my job) or a diagram of MVC, which in itself seems of poor value.

While pictures do speak a thousand words, I think code does speak more efficiently to most developers. So I'd be interested in knowing what people think. Do you prefer a screencast approach of demoing step by step what is going on, or have an introduction to the concept of MVC with nice diagrams, arrows, blocks and what not? I tried both and felt the tutorial approach worked better, but from the presenter side of things it's always difficult to make those judgement calls.

Lots of mistakes in the demo

Yeap, some glitches here and there happened. Some, like the exception thrown when a view is not found, were on purpose to demo a feature, some others were due to my poor typing. On an interesting note, when presenting just like when working, apologizing for something no one has complained about usually seems to trigger complains that otherwise would have been silent. From now on I think I'll stop apologizing for my typing errors and rely on my audience to correct me (which I really like because it means they're reading and understanding the code as I type it. Spot on!)

The examples were poor

Oh, I did like my Bingo game. I'm just sick and tired of the same stuff everyone does with Northwind / NotNorthwind / Southwind. Storefront is there to provide you with an end-to-end real demo and does it so well. I'll stick to my guns on that one, boring things are one of the reasons I don't work in the city anymore :)

Conclusion

What worries me slightly more is the discrepancy between speaker rates and overall session rates, which leads me to think the presentation itself was less than excellent. I think it really comes down to two issues: expectations should be managed to reflect the code-intensive nature of the presentation, and the content is probably slightly too complex, with too many points being presented, including containers, dependency injection, inversion of control, testability, c#, javascript, html, etc.

On the bright side, only one of you has not been satisfied by the content or the presenter, with 67% rating the session as Very Good or Excellent, and 72% rating me as Very Good or Excellent (see my head growing out of proportion!), so a massive thanks to all of you for making this the presentation I've enjoyed the most so far.

P.S. I seem to remember two people chatting and laughing away during parts of the presentation at the back of the room. A good thing I had my back to the audience the whole time or I would have given the eye. Presenters do put a lot of effort in preparing those sessions, if the content or the presenter doesn't interest you, I apologize for failing to make the subject interesting to you, but I'd rather you stayed quiet or left. The law of two feet should apply, even during a presentation.