Scrabbling up the Learning Curve
A few months ago I was at the peak of my powers.
I was leading a team of ten C# developers building a huge project on Microsoft’s .NET platform. I had been working on the Windows platform for years, and there was rarely a question from the team I couldn’t answer quickly and confidently, drawing on a deep well of past experience.
Come to CITCON
Some people think there is no conference for those of us who care about CI and testing, but oh yes there is.
As an avid reader of this blog, I know that you, like me, realise that continuous integration and testing are to software development what the spirit level and the plumb-line are to the construction industry: powerful tools that will one day be regarded as essential for any professional practitioner.
If you fancy meeting other like minds, come and join me at CITCON, the Continuous Integration and Testing Conference. What could be finer?
Story Driven Development - Just Another *DD?
Bryan Helmkamp, who maintains the handy little library webrat, did a talk recently at GoRuCo 2008 which explains his experiences using RSpec plain-text stories to build ruby-on-rails applications in a manner he calls ‘Story Driven Development’:
Before code is written, the team produces executable scenarios for a user story.
9 Techniques to Save you from the Bug-Swamp
How many unresolved bugs are there in your system right now?
Yes, yes, smarty-pants: the ones you already know about.
Ten? Fifty? Two hundred? More?!
I find it frighteningly common to see teams let a huge backlog of bugs build up. They set up a trusted system like Jira or Bugzilla and then use it as a dumping bucket for a whole variety of irritations, glitches, missing features, and genuine defects.
Pretty soon the list becomes un-managably large. Nobody dares go in there, because it’s full of bad news. This drains the team’s energy and morale.
Getting on top of, and staying on top of your bug list is hugely important, and I outline my thoughts and experiences on achieving that below.
Software as an Art Form
I just came across an article written five years ago by Richard Gabriel proposing a university course run along the lines of his own Master’s in Fine Arts in poetry. The idea evidently gathered some momentum at the time, but now seems to have come to a halt.
What a shame. I’ve had an idea to get back to university on a ’some day’ list for a while, and this would have been pretty much exactly my thing, I think. Seems to me like it was just an idea ahead of its time… I wonder how popular something like that would be now, with the increased focus on Quality that is sneaking in the back door behind the noisy razzmatazz of agile adoption.
Casting with ‘as’ in C#
Anyone else hate this?
Doofer doofer = GetWidget(widgetId) as Doofer;Then, somewhere miles away from this innocuous little line, I find that my doofer is unexpectedly null. This is a great way to introduce hard-to-trace bugs, unless of course it’s complimented with guard clauses everywhere to test for nulls, which most of the time means unneccesary clutter.
What’s wrong with good old…
Doofer doofer = (Doofer)GetWidget(widgetId);?
In this second case, if the result of GetWidget() can’t be turned into a Doofer, I’ll get an exception thrown right there and then. Assuming that my code here works specifically on doofers, I may as well spit out an exception right up here - how the heck am I supposed to work with this other type of widget you’ve sent me?
I think the only time to use a soft ‘as’ cast is in the tiny minority of cases where you really don’t care if the result of GetWidget can be turned into a Doofer. It seems to me that 90% of the time, you really do care, and you’d like to know as soon as it’s not. Even in that 10%, you’d probably be better off using a null object.
It’s a shame, because the ‘as’ operator is a bit more readable, and we all hate having to slam all those brackets in everywhere. Fortunately, C# provides a little-known solution to this, known as implicit casting.