on determinism
a concept that has “bubbled forth” in my thoughts of late is that of determinism and predestination, particularly in the context of technology and technology businesses.
a bit of foreshadowing may be in this entry, but i hope to expand on the thoughts a bit today.
this will probably be a bit scattered at this stage, but it will undoubtedly evolve…
some tools are purpose-built and it’s difficult to imagine alternative uses, but that comes from a set of preconceptions and expectations. in technology, i’ve often said that the biggest problem with geeks is that they all know how best to do something (or some variation thereon). computers and networks are so flexible, and there are so many ways to solve a problem, that nearly every individual can craft their own solution. you can select hardware, language, platform, api, build on an existing standard, create a new one, use an existing tool, modify an existing tool or create a new one. the possibilities are endless. and that’s ok, but there is a lesson here in that the tool-maker cannot predetermine how the tools are used.
if i hand you a rock, will you use it as a hammer, a paperweight, a decoration, a weapon, or something else? if i hand you a rock with a handle attached, the paperweight application becomes less “obvious” – but it isn’t precluded – you may not even recognize the handle as a handle. i cannot determine the ultimate use of the rock.
i worked in a well-defined technology space for some time (years, really), under the intentionally-ambiguous and very internet-bubble-esqe moniker st group 6 (see, ambiguous 🙂 ). my work on the st group 6 project is all about providing a general, enabling technology platform in a huge market. i still think it’s a viable project, but it’s also very capital-intensive, and i am not capital-rich.
recently, i “switched gears,” to look at a concept i’ve worked on, with varying degrees of intensity, since the late 1980’s. this work has come together in various forms, most recently under the project name “eclipse.” (old habits)
anyway, in reviewing old notes and documents, i’ve come to the conclusion that much of my failure in this space is very directly associated with my own preconceptions of “how things should be” or “how things should be done.”
to address those failures, this time around, and with the perspectives gained from the st group 6 work, i’ve put considerable thought into the concept that i don’t have all the answers. i can’t determine the destiny of the tools i create. of course, i have to try, because i have to have some set of assumptions to build a plan upon (but that’s another issue for another time).
certainly, i have a purpose and an intent with this project. i have goals. i think this is important work. i firmly believe that “how things are done” is fundamentally flawed, and i have a better idea. but it is the nature of humans and human creativity to take the tools available and push them. eclipse is about building tools that serve a particular market. this much i know. what i don’t know is what other markets will find these tools interesting and useful. i don’t know how the tools will be “hacked.”
i have learned. i intend to build flexible, extensible tools for this market. and i will be amazed and awed by how they are used.