Blacksmithing and Mobile Software Development – Episode 5 – Measurement

My primary hobby in my off-time is blacksmithing.  Blacksmithing as a profession effectively died out in North America in the 1950s/1960s, but was reinvented as an art during the 1970s. There are still incredibly few blacksmiths still around, but it is an extremely rewarding hobby. This series will examine how blacksmithing and mobile software development, two seemingly disparate pursuits, share a lot more in common than you might suspect.

In Episode 5, I will discuss measurement, and how it applies to blacksmithing and software development.

I often explain that machinists measure down to a thousandths of an inch, woodworkers measure down to a 1/16ths of an inch, and blacksmith measure by looking at it and saying ‘that looks about right’. Its mostly an exaggeration for comedic effect, but in many cases, it does actually reflect reality. This is not because blacksmiths are lazy, but rather because accurate measurement is often impractical and unhelpful. Measuring something that is 2000 degrees is imprecise and somewhat dangerous, whereas waiting for it to cool down every time just to measure it is wasteful. When making a piece of art, there are often outside dimensions that important to stay close to, but the dimensions of the components are best judged by eye, by what looks good and functions well. Often you have a rough idea of what you want to make ahead of time, but quite often the process of making it changes what the end product needs to end up being. Blacksmithing is far more art than science.

Similarly, software development is a difficult thing to accurately measure. When you design a feature, or fix a bug, you typically have a high level idea of how you’ll go about fixing it, but almost never do you know every step along the way ahead of time. This is particularly true of bug fixing, as I often say, in order to know how long it’ll take to fix a bug, I need to know how to fix it, and if I knew how to fix it, it’d probably be fixed already. So while we can come up with rough estimates of the overall time a given task will take, it is extremely difficult to estimate how long each subtask will take, and even the overall estimate is typically something that needs to be revised as the implementation progresses.

In both blacksmithing and software development, there is no substitute for experience when it comes to measurement. An experienced blacksmith will be able to look at a section of steel from three feet away and tell you whether its 3/8 of an inch or 1/2 an inch. A software developer with decades of experience will, in aggregate, be able to estimate how long tasks will take with surprising accuracy given the lack of information typically available at the start of a task. In my opinion, there is no substitute for experience here, there’s no formula you can learn at school, and since each developer uses different techniques and approaches to problem solving, their estimation techniques are generally not transferrable.

All that being said, measurement is nevertheless still very important in both blacksmithing and software development at the right times. If you are making a table with mortise-and-tenon joints, those measurements need to be precise or you’ll end up with a rhombus for a frame instead of a rectangle. In software development, the ability to accurately provide estimates for product delivery is critical. Similarly, the ability to measure, through usability testing, the effectiveness of an application can be the differentiator between functional and exceptional.

One way that measurement is used in software development that I’m not personally fond of is to assess the performance of software developers. Statistics are run, developers are compared based on number of bugs fixed and features implemented, number of regressions caused, accuracy of estimates and so forth. These numbers, however, cannot take into account the relative difficulty of those bugs and features, making it a comparison of apples and oranges. I’ll point out quickly that on a personal level I always come out very well on the basis of these types of comparisons, this is very definitely not a case of sour grapes, this is a case of me believing, quite strongly, that the approach is flawed. You do not judge a blacksmith’s skill solely by determining how quickly the piece was built or how close to the original measurements it comes, you judge that blacksmith primarily by how functional and beautiful the end result is and how efficiently the work was done. Similarly, in my opinion, the primary way to judge a software developer is by looking at the code they write, not by some statistic. There is no shortcut here, you need to spend the time to look at the work they’ve done and how long they took to do it. Yes, its faster to just punch a number into a spreadsheet, but being a manager, assessing someone’s performance, shouldn’t be about fast, it should be about right.

One of the things that attracts me to both blacksmithing and software development is that they are both, at their core, problem solving. This is not assembling the same components in the same way in a factory every day, this is a new problem with an unknown solution virtually every day. Measuring the unknown is fundamentally impractical, but at the same time, we musn’t use that as an excuse for not measuring those things that we can measure, that we need to measure.