Hunt Blog

A little bit late but....

The presentation by Tom Opgenorth on Monorail was fantastic. It gave me ideas as to how to use Microsoft's MVC in the current project I am working on, and gave me ideas as to some of the pain points of MVC and IoC frameworks.

The number one thing that has always bugged me about MVC and IoC is that everything resides in an xml/config file. The concept of being able to plug and play is fine with me; you can change things out without recompiling. A simple flip of a switch and *shazam* it's all hooked up and running.

The problem is in the details.

First (two-part-er)
a) Post-deployment troubleshooting:
When stuff inevitably breaks (I know I am the only one who has ever written code that has broken... but please bear with me), it is often difficult to resolve where the break happened or how to fix it. I know you can write applications more robustly but, when the story or use case has been coded... we're forced to move on. The business value of writing an application that can heal itself or give meaningful feedback when "stuff" happens is, far too often, lost on product owners or business analysts. The functionality delivered to the end user is so high on the list (and, rightfully) that these sorts of details are neglected.

b) Post-deployment maintenance:
A side issue is that, in many of the larger organizations I have worked at, developers are expected to hand off the application to a deployment/maintenance team to manage. Far too often there are so many other applications on their plates that this type of application complexity puts me squarely back in the seat of managing the application when it breaks. Having configuration files for non-developers to be able to touch and muck with increases the fragility of a deployed application. Just reminds me of installing any number of crazy combination dependencies to get some Linux applications working properly on older versions of Linux (that didn't have aids to help manage dependencies). This puts me squarely back into the saddle of maintaining this application or into documentation hell and introduces a dependency of the client on my services. Great for job security... if that's the type you are looking for.

Second
Lack of Testing around the "And then magic happens":
Separating out dependency instantiation from class implementation is a good idea. It helps set up an environment where people can work on/test parts of the system independently. But... with most IoC Containers I have seen (though this is only through demonstrations), the wiring up of the configuration of what class to instantiate the dependency is often lacking testing. This can result in an exception being thrown at run-time (arguably the worst time to throw unhandled exceptions) if no dependency is actually wired up. Maybe this is a call for a profiling application to check class dependencies and ensure that they are all wired up within the IoC framework and included as part of the release criteria for the application?!?!

Anyway, watching Tom's presentation was very thought provoking. He did a good job of getting through a lot of material. Thank you to the Edmonton .NET User Group for facilitating a great evening.

I was contacted by Patrick Smacchia and extended the opportunity to try nDepend. I took this as an opportunity to learn more about the metrics beyond my more familiar test coverage (nCover, nCoverExplorer), code style compliance (FxCop and Code Style Enforcer), and the like.

My first impression was that I was confused by the interface. It looks confusing. When I click on different parts of the UI, other things change and flip around. I didn't understand the metrics being measured and how they were being displayed.

Okay... the first 5 minutes were up and the curiosity bug hit me. I wanted to know what all this information was about and how to better use this tool. I went to the web site and found the online demos on the Getting Started page. There are (currently) 8 separate demos available. After only the first two (6 minutes) the light bulb started to turn on. There is a LOT of information to digest. This tools reports 83 different metrics at different levels of analysis. The investment in online tutorials and web site opened a huge door. To be sure, there's a lot more for me to sink my teeth into in this tool.

One of the coolest features I discovered was that, when you click on the bubbly report in the metrics window, the toolbar presents a drop-down where you can select which metric you want reported in the metrics window. The nice part about that is that you select the metric to report on, the report generates, and all you have to do is look at where the biggest squares are (left to right) to find out what the biggest culprits are to take a look at. Pretty slick!

When companies advertise for developers to come in to write a maintainable application for them they (solely from a business perspective) are often looking for an application to be developed that does what it's supposed to and comes with little to no maintenance after the fact (for the agilistas out there... "As an application owner I want to deploy an application that does what it is supposed to and doesn't have high cost of ownership after delivery by requiring full time monitoring/bug fixing staff"). From a development perspective, we often only think of a maintainable system as code that's sufficiently tested to help avoid having changes to a system have cascading effects. I believe that there is a gap in what defines a "maintainable" system and leads to "Maintainability Mismatch Impedance". Certainly the two are related but, certainly, they don't fully address each others' needs.

It is generally considered poor form to have to have Visual Studio installed on your build machine as you should be able to build your product without a dependency on the IDE. I was informed that the Visual Studio Setup and Deployment Projects (used to create the msi files) can not yet be compiled and linked without the use of Visual Studio. With this understanding, we used wix to perform the automated build of the windows installers. After downloading the binaries and reading the help and getting started tutorial we had a completely automated  build and deployment process. This took less than 3 hours to get up and running. Definitely a delight.