When I was a child, my dad would do things around the house, maintain our cars and fix things that could be fixed. As I grew I was often involved in helping him. At first I think I just got in the way, then I was an extra set of hands and later, I was fixing stuff. I remember a conversation we had about his tools where I was really focused on the why Craftsman Tools. Keep in mind this was back in the eighties and I was about 8; I am not sure who the main competitors were to Craftsman but I don’t recall any brands of tools from back then other than Craftsman. I wanted to know why he used that brand. When we went to Sears, they were way more expensive than anything else I saw. His reply was that they were better and they backed it up. There was a guarantee that I understood as follows: The tools will perform and they will not break or we will replace it. How could they do this, I wondered? He explained to me that they believed in their tools so much that they were willing to replace tools that did not perform. He said they could get two things out of this approach. First, they built goodwill with the customers who did have a problem tool and second, by collecting the tool that did not perform they could learn how and why it failed and use that information to make the next product better. This is important to me now because I am five plus years into learning about (web) software. As a cog, I try to remain objective about software even though I have my biases. Just because I believe what I know is better does not mean that it would be better in all situations. In the past few years I have read much about competing web technologies and the developers and engineers that build software with them. I have worked in large enterprises and small (kinda shady) internet companies. All I know is what I have seen. In the enterprise I have seen:
- The creation process for static web content take weeks and months
- The development of brittle solutions that are revisited over and over as the business evolves
- Developers who use process to redirect and avoid simple, no-brainer web work that any professional website needs to do
- The business substantially fall behind the curve of progress on the web
In contrast, at the small (shady business model) company I have seen:
- A small team build, scale and maintain a platform that performed
- Co-workers who were willing to step out of their niche to solve problems that affected the business
- Changes (both mine and others) go live in minutes instead of weeks and months
- Problems addressed instead of added to a list
So with my sample size of one, what does this mean to me? I understand that there is a reason large enterprises and the companies they rely on will always be around. I also understand that because of the brittle approach that requires means there will always be opportunity for the little guy who says, “I can do this better.” I also have firmed the belief that it is neither the tools in use or the developer employing them that makes software useful, average or buggy. Both matter, if the tools aren’t easy to use then problems are harder to solve. If the developer is average or clueless then they will produce software that is average. Tying this back to the conversation I had with Dad all those years ago I wonder what I can do so that the work I produce can be of such high quality that I could attach a guarantee like the Craftsman guarantee that I remember form the eighties. Is software to complicated? Did I start down this path to late in my life to reach the high level of excellence? Can I produce work and solutions for people that I am so confident in that I would back it for free should it not perform as designed? I don’t know the answers to these questions but I am on this path and will keep putting one foot in front of the other and see where I end up.
