March 2009 Blog Posts
I’ve been thinking recently about the variation in the field of software developers and what properties we can ascribe to those who we might call great. This comes from a desire to continuously improve as a professional software developer, having an idea of what makes someone great gives me a set of attributes to aspire to. A naive interpretation would be that a great developer writes a lot of code but I find this to be flawed. Lines of code is a terrible metric, it penalises more effective solutions to many problems. So perhaps measuring on features delivered is...
Time constraints and a need to deliver functionality quickly are one of the most common justifications I encounter for choosing expedience over proper design and practice in implementing software. I find this to be short term thinking at it’s worst, resulting in delivered systems that will ultimately cost far more and have significantly decreased utility over time. Software that works right now has no business value. This statement seems to be false, even absurd. Of course it has value. It can be used to write documents, process orders, contact customers and do all kinds of business functions. Yet I...
It has long been considered a good practice that software be loose with its inputs and strict with its outputs. This ensures your software can work with a wide variety of third party systems, tolerating their output peculiarities and producing clean data that may be widely accepted. The web and the wide variety of truly terrible HTML that may be found on it is particularly good example of this practice at work. There are however cases where being strict with your inputs is appropriate. These tend to be when the input is a request to perform an action. In...
From the IDisposable Dispose method documentation: If an object's Dispose method is called more than once, the object must ignore all calls after the first one. The object must not throw an exception if its Dispose method is called multiple times. But what happens in you call Dispose twice on ReaderWriterLockSlim? A shiny ObjectDisposedException. Oops. For the record I discovered this while unit testing the multiple dispose behaviour of one of my own classes not in production code. Annoyingly it makes testing the disposed behaviour of my class difficult as my tests will...
One of the real killers of the utility of unit tests that I have encountered is having a test set that is brittle and prone to breaking. This leads to a situation where even minor changes are large efforts due to the changes required to make all tests pass. We can therefore compare the overall utility of test sets by the likelihood of tests breaking due to unrelated changes. Ideally this likelihood should be very low and test breakages should indicate genuine bugs introduced by a change. Complex tests that have multiple assertions and expectations are a particular source...
After spending some time resolving a number of code analysis warnings, here's a massively incomplete list of small things to do to help you produce better code. At the project level: Turn on "Treat Warnings as Errors" on your projects. This can be a very big thing indeed if you do it in a project with lots of errors, so do it early. I've discussed this previously. Turn on code analysis and have code analysis errors treated as errors. Be aware that there are legitimate cases where warnings should be suppressed....
In practicing TDD it is reasonable to be concerned with the size of your test code. After all test code must be maintained and maintenance effort correlates to code size. Excessive test code is therefore costly. What then should drive how much test code we have? In my opinion there is one primary question in determining the amount of test code required: How much test code is required to properly exercise the system? Unit tests exist to specify and validate the behaviour of the system (as units). You have enough test code when the...
Every now and they I run into something that makes me wish C# was more dynamic. Today’s example is playing with delegates. For instance the following works: public void Test()
{
Func<object> blah = Blah;
blah();
}
public string Blah()
{
return string.Empty;
}
This is valid because the return type of the method is always more restrictive than that of the delegate (that is it is covariant). Unfortunately this breaks down with delegate assignment:
public void Test()
{
Func<string> blah1 = Blah;
Func<object> blah2 = blah1;
blah2();
}
public string...
Recently I’ve been working with some systems that don’t build as fast as I’d like. I’ve therefore taken a project and made some changes to attempt to optimise the build speed. This post discusses these optimisations. In gathering these numbers I’ve run each build multiple times and discarded the first of each builds to account for setup times and the like. I’ve normalised each figure against the time taken by the initial unmodified build runs. This isn’t particularly scientific but it’s adequate for this usage. The build run includes the time to build the system and to run all...