Software Engineering

Framework Blues

Steven Mitcham — Thu, 10 Jan 2008 18:46:12 GMT

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

Steven Mitcham — Tue, 30 Oct 2007 16:27:07 GMT

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.

Jeff Answers My Unit Test Question

Steven Mitcham — Wed, 24 Oct 2007 18:34:58 GMT

Earlier Jeff Brown posted some comments on some new features of MbUnit v3, which I responded to by how to answer the NUnit critics concerning isolation of test fixtures.

Jeff responded with what I think is a pretty good answer. I'll have to think it through for a bit.

I believe that my original question was not so much a question of the validity of the approaches, but that after reading the book, I found that I had not considered the original issue of isolation via new test fixture classes.

I started with NUnit as my first experience and not JUnit, so the set and tear down mechanisms were just 'what was' rather than what should be.

As I've said in my other posts, I am often constrained by decisions made from outside my organization and the choice of unit testing framework is no different so having the best arsenal of responses to the unavoidable battles for these types of choices is a good thing.

Why half implementations of TDD don't work

Steven Mitcham — Wed, 12 Sep 2007 13:26:32 GMT

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

Steven Mitcham — Fri, 07 Sep 2007 02:59:38 GMT

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.

Solid build process

Steven Mitcham — Thu, 23 Aug 2007 04:36:24 GMT

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

Steven Mitcham — Mon, 20 Aug 2007 18:12:23 GMT

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.