Development In a Tesseract

Framework Blues

2008-01-10T12:46:12-06:00:00

Being an ultra-introvert, it always freaks me out when a comment I make brings me out from under the radar.

I posted on the alt.net list to a thread concerning the pro's and cons. Jeremy Miller posted an opinion on my comment, and I followed up with a comment on the post.

As a reflection on all that, I'd like to say that I think that in priciple I'm inclined to agree with Jeremy. In practice, I'm stuck with the Framework that led to the post.

I believe that my ideas of what a 'Framework' should be is changing. Jeremy talks about code generation and the templates and IDE productivity stuff, but I think that I'm going a different route myself, although it wouldn't be the first time I was wrong.

What I've been currently trying to do, with the help of the language enhancements (anonymous delegates, generics, lambda expressions, etc.) is get libraries of limited scope reusable objects that can be modified through the use of generics and delegates to perform instance specific work.

What I am working on right now involves a ton of reuse, many of our systems are basically made up of building blocks that are identical in specification. Our framework involved creating blocks of reusable objects, along with the rules of validation, that could be dropped into place.

For the first round of systems (which were almost identical), this worked very well; however, as more less similar systems were included, the framework started to show strain. My original point was that the framework would have been able to be adapted or evolved into a better form, except that the development contracts were written in such a way as to preclude any further development on the system in question (a bad choice by program management). Once we finally got the money in place to make updates to the framework, the enhancements are stretching the capabilities of the framework.

One of the biggest issues I've had recently was to try to convince a team not to use the system for a project that didn't fit well with the design intent with the framework, and they suffered exactly the fate that Jeremy mentions in his post and would have been better off starting from scratch.

A missing piece to CMMI

2007-10-30T11:27:07-05:00:00

I've been working in organizations that adhere to some level of the CMMI for some time now. And we are trying to fit what we can of agile programming into our process, and hopefully are achieving better results while still keeping the structure required of our contracts.

A long time ago I ran across this article which discusses some of the levels of process that are often encountered in the wild, but rarely discussed by SEI.

So here's the The Capability Im-Maturity Model (CIMM) as envisioned by Capt. Tom Shorsch USAF.

Work Life Balance

2007-10-24T22:09:01-05:00:00

Chris Sells has been writing on working at home, and Scott Hanselman has as well.

As for myself, my employer frowns on working at home, although I am on a laptop, and we do have a VPN. Several times I have gotten permission to work from home simply so I can focus on one project at a time and actually accomplish things.

My normal course of action is to keep accepting small tasks that 'should be done easily' and then have them pile up as the daily fires appear and consume my time.

Ultimately, my to do list threatens to suck my computer into the void due to its massive gravitational weight and I have to blow everyone off and get the plate clean again.

I'm not sure if working full time from home would work from me, I certainly doubt my employer would buy into it. But currently, I'm sitting at the office trying to play the same game of catch-up. It's 10pm and I'd rather be home to do this work.

Extension Methods and Dictionaries

2007-10-19T15:24:54-05:00:00

I have started looking at improvements to the NMock2 code with respect to writing a branch of the code in .NET 3.5.

The availability of extension methods in C# 3.0 have solved a common code issue of mine where I want to use Dictionary.TryGetValue to see if there is a value in a dictionary for a given key and create a default if not. Which leads to the following code.

public static class ExtensionMethods
{
    public static U SafeGetValue<T,U>(this Dictionary<T,U> dictionary, T key)
      where U:new()
    {
        U value;
        if (!dictionary.TryGetValue(key, out value))
        {
            dictionary[key] = value = new U();
        }
        return value;
    }

public delegate U NewInstance<U>();

    public static U SafeGetValue<T, U>(this Dictionary<T, U> dictionary, T key, NewInstance<U> newInstance)
    {
        U value;
        if (!dictionary.TryGetValue(key, out value))
        {
            dictionary[key] = value = newInstance();
        }
        return value;
    }
}

Why half implementations of TDD don't work

2007-09-12T08:26:32-05:00:00

Currently I'm in the process of reviewing some code that was written and then had MbUnit tests written to back flush the requirements. Since I'm part of a more traditional shop, the code has already been peer reviewed. The tests, of course, revealed errors in the code that weren't caught as a part of the peer review; so the code was corrected and re-reviewed. Of course, when the tests were reviewed, the tests were found to have errors, which precipitated further changes.

I addressed the approach we are using to fix this effect (although the fix won't be perfect due to the limitations of our process) in the post How to make the most of traditional peer reviews.

Infragistics Pain

2007-09-06T21:59:38-05:00:00

It is entirely possible for something to have too many features.

In response to a question from a co-worker, we spent approximately 2 hours digging through the options and model structure of the Infragistics UltraGrid control to discover the way to get the bound rectangle of a row for a drag operation.

While I get the desire for everything to be super customizable, at some point it seems like overkill.

Debugging Visual Basic 6 code through Visual Studio 2005

2007-08-23T11:34:14-05:00:00

Today I had an issue where an application that as a mixture of .NET, VB6 and C++ code needed to be debugged. Since the component that I needed to look at was in the VB 6 portion, I attempted to debug from VB6 only to be met with a variety of bizarre errors.

I don't have visibility into the rest of the application, so I continued with the .NET 2005 debugging session, which executed correctly, and noticed that I could set a breakpoint in the VB 6 code when the unmanaged debugging support was turned on.

The debugger visualizations are not quite correct, the .NET objects were showing up a <void>, but I was surprised to see that you could do this at all. I was able to trace through to the source of the error and move on.

BindFailures MDA in VS 2005

2007-08-22T23:37:55-05:00:00

While debugging a COM Interop error I came across the fact that Binding Failures can now be trapped in the IDE using the BindingFailurse MDA (Managed Debugging Assistant). Up until today, I'd still been using the FUSLOGVW utility to track down binding failures.

Solid build process

2007-08-22T23:36:24-05:00:00

Experiences today have made me realize how important a solid build process is. I spent 6 hours today trying to get a development environment in a virtual machine to build the source to a component that I needed to help debug. The actual debugging session has taken less than five minutes and will probably take only about another 30 minutes tomorrow.

Making the Most of Traditional Peer Reviews

2007-08-20T13:12:23-05:00:00

In the traditional waterfall development process, one of the key pieces of quality assurance is the traditional peer review. In theory, peer reviews allow additional coders to view the code and hopefully discover issues before the make it into the release of the software.

Unfortunately, in practice, the reviews do not really add meaningful value to the development process. Typically, the reviews are done near the end of development, and are almost always superficial in nature. The first few files in the review get a decent treatment, but quickly the effort turns to just validating the coding standard and perhaps finding some examples of the reviewers pet issues. In an effort to reduce this tendency, often limits are imposed to the number of files, or number of lines that can be placed in a review, but that only adds the additional overhead of more reviews.

My team is currently involved in a very large coding effort and our peer reviews are encountering the same kind of symptoms. In an effort to improve the situation, I've been moved to make the following suggestion in how to deal with peer reviews in the future. Some of the remedy involves borrowing techniques from agile development to help focus the point of the reviews. It is possible that something similar can be done without the use of the agile methods, but I believe that the method described is a good mix of the traditional and the agile.

The Steps

First, it is important not to review things that are better reviewed by a machine. We are creating a gateway procedure that uses the tools available to us to eliminate the common, clerical findings that clutter up most peer reviews. The starting point is using a tool, such as Resharper, to assist in getting the code into the standard format. Also, tools are used to measure complexity as well as check against basic coding standards. We are currently using the Static Analysis function in Visual Studio Team Developer Edition. Finally, we have implemented the requirement for executable unit tests (in MbUnit) that are passing and have at least 85% coverage. By letting the peer review moderator ensure that the code has been run through these tools first, and that the code is passing a basic level of quality before involving more than one other person in a review.

Once the review is allowed to go foward, the 'peer review' is actually divided into two parts. The first review takes the set of unit tests and matches them against the requirements. The purpose of this review is two-fold, to ensure that all the requirements have been satisfied, and to ensure that as written, each test actually tests what it says it does. The code the unit tests are executing is not reviewed at this time.

Given that the units test are passing (we would hope), then if the requirements map to the tests and the tests test what they say they do, we have a level of confidence in the code under test. Additionally, if a problem is found with the requirements, or the tests, then we know that it is fruitless to continue with the rest of the review cycle.

After the review of the unit tests is complete, and any findings in the tests have been worked through the codebase, then we proceed with a review of the code itself. Because of the earlier steps, the reviewers understand the requirements and have reviewed the tests which should give them a basic understanding of what they are actually reviewing. Additionally, because all the clerical noise and basic 'correctness' has been dealt with via tools and the earlier reviews, the reviewers are free to examine the more important (and more difficult to automate) issues of maintainability, and hard to find errors such as memory leaks.

In the pilot projects where we have run this process all the way through, we are seeing additional benefits from our code reviews.