Over the years I have had many a heated discussion with colleagues about what I mean when I talk about creating software. I have always had a difficult time explaining my perspective and more importantly I haven’t been successful at getting across the fact that my perspective isn’t the only one or even the correct one for every situation. I have been looking for a suitable analogy to bridge the gap and I think that I have finally found one in my other passion: food.
At its core whether you go to Sukiyabashi Jiro, TGI Fridays or your own kitchen, food is a basic necessity of life. You don’t have to have even the most basic of culinary skills to go into your kitchen, grab some bread, slap some peanut butter and jelly on it and have a meal — a damn tasty one! — that can consistently sustain you for years. Similarly, you can go to any webpage that you find appealing, grab the source, change a few obvious elements and come up with a completely new and useful webpage on which to build a business.
With a little gumption and a little practice, you can muddle through almost any recipe and produce a palatable meal. Sure, there’s going to be a few recipes that elude you but by and large you’ll do just fine. You don’t need to know the difference between baking soda and baking powder in order to bake a cake. Just follow the recipe, use online resources to help you with any substitutions you might need and a tasty cake you shall have! Similarly with all of the development resources that are available today (e.g. stackoverflow) you can “follow the recipe”, cobble together almost any project and successfully use the results to grow a business.
My in-laws ran a successful restaurant for 30 years in which they made enough to put three kids through college and still have enough to retire on. They had no training in managing a restaurant. They didn’t know how to structure a kitchen to maximize workflow and minimize waste. Hell, they did it while barely speaking English. With enough chutzpah and some common sense you can get a decently-sized team to be successful for decades.
To sum all of this up and to state my first point plainly: you don’t need training, discipline or rigor to successfully sustain a career in software (or food service) that spans decades. Period. (Look: Get over it. It’s true.) If you do have training, discipline and/or rigor then you’re going to have that much more of a leg up on the competition.
So what am I talking about when _I_ talk about creating software? I’ve managed to narrow it down to a few points. (One of the primary reasons that I wanted to write this post was to get the input of the community to help me isolate and focus my intent to make it succinct. Please send along your thoughts! (Yes, I know that I have OCPD. In fact I think that it’s one of the prerequisites to all of this. So no need to restate the obvious.))
- Life-long pursuit of improvement and learning: Lifelong learning and self-actualization are the foundation. This isn’t something that you do between 9 and 5, Monday through Friday. This is a lifestyle. You must have a passion for continual improvement and learning.
- Focus on consistency: The same problem must produce the same solution every time. There must be zero variance. Again, I’m talking about a lifestyle here. Doing the same thing twice and having any difference between the two leaves you with a gnawing feeling in your gut that no case of cheese puffs can quell.
- Focus on quality: Consistency isn’t useful if it doesn’t meet the requirements and expectations that were agreed on. (This in turn requires that the requirements and expectations themselves are of a high quality!) Fit and finish are an obsession even if no one ever sees behind the curtain.
- Focus on urgency: All of the above is an interesting mental exercise but if it takes an order of magnitude or more time to do then it isn’t useful in practice therefore it must be based on a firm foundation of urgency. Have I removed all of the superfluous movements, processes, etc? Is each iteration washing away what is unneeded resulting in a better performing process?
If you’ve never seen Jiro Dreams of Sushi (available on Netflix Streaming and Amazon Prime) I highly recommend it. It does a much better job than I am explaining this life-long pursuit of the perfection of an art.
To wrap this up: When I talk about creating software, I’m talking about employing the techniques learned through a lifetime of focused and disciplined practice. Of course you can successfully build software without these techniques but that’s not what _I_ mean by it or want from it. Just as there are situations in which it would be wasteful/not well received/counterproductive to send someone to Sukiyabashi Jiro, there are situations where using someone with my approach to construct software is not appropriate. On the flip side, there are situations where it is only appropriate to go to Sukiyabashi Jiro, and the same is true with software.
Please send along your thoughts!