As I mentioned in a previous post, I see software as a creative process, an art form. So this is a post about the other creative art form that I enjoy, bobbin lace making … like this.
A small part of a Bedfordshire lace edging, pattern by Christine Springett from an 18th C collar, completed 2014
One of the reasons my brain starts to fry when I’m asked about suitable metrics to measure the performance of a development team, is because I’m struggling to answer the question “how to you measure art?” So, how do I measure my lace?
Well sometimes with a tape measure, sure … wedding garters tend to need to be about 40 inches to get the ruffles right.
But there are other ways too. You could count the stitches but that would be a bit pointless. We often count the number of bobbins used, and whether the threads “run” or have to be sewn together in separate sections; these are signs of the complexity of the piece. And yes, I can count how long it takes. A garter normally takes about 1.5 hours per inch, the piece above was worked slowly over about 2 years. Of course, I have often an idea when I want something finished by – I may give my lace away so the deadline is Christmas or a birthday – so hitting the target date (actual vs estimate) is sometimes meaningful. And sometimes not – I did several other pieces in the 2 years on the piece above, because they had a higher priority. Does that mean the edging is “bad”? No.
You can also count the number of times I rework parts of a pattern to get it right. Or the number of defects left in the finished article. And you can turn it over to look at the back, and see how neatly it is finished (like doing a code review).
The things that are most important to me are more subjective … Does it have “wow” factor? Does it do what I (or the person receiving it) want it to do? What do my lace-maker friends think of it? These fall more into the realm of user & peer feedback.
And finally, did I learn something? My first attempt at Bedfordshire lace was not very good, but this piece is the culmination of 20+ years of practice. I got better (neater, quicker, more complex, more wow) along the way. Some learning pieces come off the pillow and languish in a cupboard because we are not proud of them. But they were still worth it, because we learned.
When I start a piece, I know what’s going to be important. Right now, I’m doing a nativity set for Christmas, a bit like this. So, this is a simple lace that I’ve done many times before. Nothing to learn. Neatness and wow factor are important because they’ll be on display every year, as is durability. Time is important if I want them on display this year. The next piece on my backlog though is a first go at Flanders. For that, time will be meaningless, neatness and wow are unlikely unless existing skills transfer readily, but learning is critical.
Does this teach us something about software metrics? We can judge the complexity of a request, and we can do code & peer review and count defects after release. These are all worthwhile in my view. But I’d like to see us judge what is important at the start of the piece, and measure against that at the end.
So “add the permission control to do roll out reports to faculty” is something we’ve done many times before, nothing to learn, neatness and durability important, time critical. But “make annotation work on PDFs and images” will be an innovation piece – a work of art. It has no time deadline, will definitely provide wow and requires significant learning. Does it really make sense to estimate how long creation takes and then judge ourselves against it? I think not.