DIY as constructive criticism

Clearly there is enormous power in using commercial grade software tools. For the most part they tend to be solid, robust and interoperable with all sorts of data and other programs. Which makes sense, since these products represent the fruits of many years of collective labor, often by extremely talented and dedicated people.

Yet I find that after a day or two using any new software tool, my first instinct is to try to build my own version of it, and then use that for a while.

I know full well that on some level this is a fools errand. One could say I am playing the part of John Henry against the railroad, or Don Quixote tilting against the collective windmills of industry.

Yet I often find that what I build ends up addressing some issue I had with the far more polished commercial tool. At the start of my Do-It-Yourself experiment, I’m not even sure what that criticism is. Yet after a day or two of hacking, I find that I have built something that addresses some essence of what I was hoping the original software would do for me — some hoped for feature or set of features that I found lacking.

This is a kind of constructive criticism. I mean “constructive” in a very literal sense, and it’s really the only practical way to practice this sort of criticism. I generally don’t have access to the source code of the commercial product in question. Even if I did, it would take far more time than I am willing to commit just to learn my way around well enough to be useful.

But taking a day or two to make my own little demo version satisfies my need to say “look folks, wouldn’t it be so much cooler if you could just do it like this?”

From time my little experiments even make their way back into that big commercial space of industrial strength software products.

When that happens, I often end up being uncredited. But that’s ok. It still gives me a thrill when I use a feature in some product that actually began as one of my little DIY constructive criticisms.

And I know there are fellow travelers reading this who have contributed in pretty much the same way.

One thought on “DIY as constructive criticism”

  1. I think one of the key reasons I do this at times is that the Big Piece Of Software is less of a tool and more of a framework/system. It says ‘put your bit here, in this fashion, and I’ll do the rest’. But it is supposed to work for any general project including mine, so it has all sorts of controls and abstractions and subsystems which I don’t need.

    Usually the Big Piece Of Software exists for some killer feature, which is why you install it in the first place. Usually it’s quite easy to take the basic idea and apply it to your own particular setup without needing a huge framework to do so.

    A bit like C++11 expropriates pieces of functional languages so that you don’t have to move platforms wholesale just to get type inference, or somesuch.

Leave a Reply

Your email address will not be published. Required fields are marked *