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 3, I will discuss how Design Thinking relates to blacksmithing. Specifically, I will discuss how it applies when making pattern-welded knives. I will also engage in a politically incorrect rant on my feelings towards Design Thinking, so be forewarned.
When blacksmithing a knife, it is critical to start with the design. There is a huge variety of ways you can design beautiful, functional knives, but each individual customer will only be interested in a subset of those. More importantly, there is a far greater number of ways you can design ugly and/or non-functional knives. Spending a few minutes, or even hours, at the beginning of the process to get the design right is critical in a obtaining a successful outcome. Moreover, if possible, make the design an iterative process during the implementational phase.
Similarly, mobile apps require arguably more design than traditional full-screen apps. The limitation on screen size imposes some unique requirements in terms of screen design, flow and layout, as does the ability to rotate and zoom the screen, as does the touch interface, and so forth.
In both cases, Design Thinking proves itself a valuable tool to employ to achieve a desirable result. The iterative aspects of Design Thinking are more important in mobile app design because implementation almost invariably affects the design. I have a rule of thumb on my team that I want them to get at least 5% of the way into the implementation before they produce a polished version of their design specs, I have seen that first 5% of the implementation change too much of designs written in the absence of concrete information to believe in doing otherwise.
All that being said, I have seen far too many Design Thinking advocates who use it too much, who view it as the only tool in their toolbox. Remember that old expression: “If all you have is a hammer, everything looks like a nail”? There was a study that was done decades again using young children as the subjects. They gave one group screwdrivers and screws, another group hammers and nails, both groups getting blocks of wood. They then let them experiment for a while. After a period of time, they gave each group both kinds of tools, screwdrivers and hammers, and both kinds of fasteners, screws and nails. The group that initially had the hammers used the hammers to hammer in nails, but also used the hammers to try to hammer in the screws, which is obviously not going to work. The group that initially had the screwdrivers used the screwdrivers to screw in the screws, but also turned the screwdrives around and tried to hammer in the nails that way. Very few were willing to try out a new tool. The lesson here is that even when we access to the appropriate tool, we often stick with the one we are most familiar with, no matter how inappropriate it is for the job at hand.
So why do I bring this up? Because the vast amount of time you spend making a knife, and building mobile applications, is not design but rather implementation. Design is a critical piece of the puzzle, but you’ll be spending the vast amount of your time doing implementation, not design. As a result, in my mind, the far more important question to me is how you go about process improvement, not how you go about design improvement. A good idea with a terrible implementation is useless.
There are, in my mind, three compelling process improvement methodologies, Six Sigma, Lean and Theory of Constraints. To oversimplify, Six Sigma says “measure obsessively and reduce variation”, Lean says “identify the value stream and reduce waste in it” and Theory of Constraints says “find the biggest remaining problem, fix it, and repeat”. Of these, my favourite is the latter.
Making a knife is, in my mind, the perfect example of Theory of Constraints. There’s a saying in knife-making that five minutes at the forge saves an hour at the grinder. Principally, this refers to the fact that if your knife isn’t perfectly straight you have to spend considerably more time at the grinder trying to correct it, something you could have corrected very easily at the anvil while it was hot. The trick is that steel which, when you are hitting it, is around 2000 degrees Farenheit is very malleable, meaning that hitting it in one place will also slightly deform it in other places in the blade at the same time. So as you progress, you end up with a knife which is slightly off straight in a number of different places and to a number of different amounts. Moreover, fixing one might make another worse. It is very easy for beginners to struggle mightily trying to figure out how to fix this problem.
The solution, as you’ve likely guessed by now, is Theory of Constraints. Find the place where its the most out of straight, fix that. When you are done that, find the next place where it is the most out of straight and fix that. Continue until the whole knife is straight. Don’t cheat, if you try to skip ahead just for convenience, you can end up setting yourself back two steps instead of forwards one.
The same process holds with developing mobile apps. As you work, solve the biggest problem first and then move on to the next biggest problem. This will get you functional as quickly as possible and, as a side benefit, allow you to accurately estimate the amount of work remaining. While you are building the mobile app, identify the area of the process that is impeding you the most, fix that and repeat. I’ve said it before but it bears repeating – the vast amount of your time will be spent on implementation, so you should be absolutely committed to making sure that that time is spent efficiently and wisely.