My friend once wanted to buy an office table. We compared some models on the internet, but we couldn’t get a feel for them. So we decided to try out some local shops. Unfortunately, the day we went out was a public holiday, and most of the shops were closed. Before calling it a day, we ended up making some phone calls and found a local carpenter who was highly regarded in the area. He told us the shops are closed, but if our need is urgent, then we can come down to his house and he will show us some samples.

We went to his house, and he showed us some samples on a pamphlet. I noticed that the furniture at his house was also pretty looking, but I couldn’t find it on the pamphlet. On asking if it was possible to make a table in a similar style, his reply was, “Oh, we don’t make that here; all of this furniture I bought from a different store.”

No matter how I frame the above story, you wouldn’t believe me that it actually happened. No carpenter in this world will have furniture in his house that he couldn’t have made himself. The reasoning from a carpenter’s perspective is simple:

  1. For an able carpenter, no functional design is too complex to replicate.

  2. Financially, it makes more sense to create furniture for yourself.

  3. A personal touch, or to artistically put it, furniture that reflects the carpenter’s identity.

Out of which for a practical carpenter, 1 and 2 are a must, and 3 may be a (good) side effect.

The reason I say all of this is because, in software, I see the opposite of the above three happening all the time. I see resumes of all the brilliant engineers and all the great products they have built at work, but when I ask what they have created for themselves and use on a daily basis, the answer doesn’t even invoke a surprise anymore. It is usually in the spirit of “Oh, I bought that from a different store.”

I have tried to come up with an answer to this exception. Partly because I don’t have any furniture that I have built for my own use. The reasoning goes like this:

  1. Creating software is complex, or at least an order of complexity higher than a carpenter’s work. And complex software needs collaboration.

    This is kind of not true. Historically, all popular usable protypes were built by a very small group, usually less than 3. Coders At Work is a good reference.

  2. Financially, it makes more sense to buy software instead of spending time building one.

    This is a valid point; some software just needs a lot of time to build and maintain. But not for smaller projects. If this is also true for smaller projects, it raises an additional concern that the current tools are just too inefficient to create something substantial in a reasonable time. Think of a carpenter working with a big saw for all the cutting and shaping.

  3. Financially, it makes more sense to work all the time building products for others and nothing for yourself.

    I think this is the major reason for not enough creation for the self. No other industry has this variance in perceived monetary value when it comes to products created for the self and products created at work. For a pastry chef working at a bakery, making cupcakes at home for the family is equally lucrative, if not more.

  4. The lack of a need for personal touch.

    This would mean that the state of usable software at present has covered all the functional + aesthetic needs of the user. Many would disagree. But even after disagreement, if there is no creation, that would mean either the engineer lacks imagination or is just lazy.

Initially, I started writing this as an exercise in thinking about the state of software. But I realized that it could be applicable for any domain where the incentives for creation for the self are hindered by some x conditions (with the assumption that creation for the self is an absolute must regardless of domain). Watching a well-crafted movie inspires us to recreate some of the scenes with our own projection in it.

The barriers to creation could be

  1. The complexity of creation, which allows us to reflect on the design itself. A functional design should be simple.

  2. The tools of creation. Maybe our tools are too inefficient. Or maybe they are just too efficient. Hammer vs. Swiss knife.

  3. External incentives, like financial incentives, shouldn’t be a barrier to creation for the self.

  4. Lack of internal incentives

P.S. Thanks to Karan for constantly pushing me to write these ideas down. Internal incentives are a mystery some times, but it is easier when you have supportive friends. Thanks to Palash for his feedback on these ideas and for providing his unique non-software perspective.