Your leaking thatched hut during the restoration of a pre-Enlightenment state.

 

Hello, my name is Judas Gutenberg and this is my blaag (pronounced as you would the vomit noise "hyroop-bleuach").



links

decay & ruin
Biosphere II
Chernobyl
dead malls
Detroit
Irving housing

got that wrong
Paleofuture.com

appropriate tech
Arduino μcontrollers
Backwoods Home
Fractal antenna

fun social media stuff


Like asecular.com
(nobody does!)

Like my brownhouse:
   an uncertain hand out into the unknown
Sunday, December 16 2007
I read something recently about the corporate research and development organs of the old quasi-monopolies, particularly Bell Labs, which brought us two of the most important building blocks of our existing global information architecture: the transistor and the Unix operating system. There's also Xerox Labs, which brought us the graphical user interface. According to the article, these labs have all been closed down and corporations have outsourced much of their research and development to universities.
It would be difficult to overstate the value of well-funded research and development, even when motivated by crass nationalistic goals (for example, the space race and the arms race). Research of this kind is a blind step into the darkness of possibilities, with no idea what will result. At its best, such research can reach to the limits of the greatest creative force in nature, Darwinian evolution, but (benefitting from the educated nature of the guesses) getting there much faster.
The most depressing moment in the article came with this sentence, "Almost no corporate labs based on the Bell or Xerox model remain, victims of cost-cutting and a new appreciation by corporate leaders that commercial innovations may flow best when scientists and engineers stick to business problems." Sticking to business problems is inherently short-sighted, maximizing return on investment in the present without concern for the future. Due to the cut-throat competition resulting from globalization, corporations have become increasingly short-sighted, leaving research to governments and educational institutions. Whatever country is most profligate with its open-ended government-funded research will probably come to dominate some phase of the future, and the country doing this probably won't be one with professed preference for faith over science and technological interests confined to Cold War-era battle equipment and surveillance gadgets.

As with corporations, we as individuals can choose to solve our problems either with or without a concern for the long term utility of our solutions. It's often easiest to do whatever takes the least deliberation, and this strategy is perfectly adequate for a wide range of tasks such as washing dishes, painting houses, or preparing food. But as the complexity of the task and the durability of the product increase, the value of long-range planning becomes increasingly important. At the level of software development, the product resembles life itself in that it is theoretically immortal and, if successful, will propagate. When one is working on software, particularly for an open-source platform (in other words, an environment supported by a community instead of a corporation), it can be advantageous to think long term. I say "can be" because many applications of software are essentially disposable. But if you, like me, are building and improving a personal repository of generic code that can be used in a wide range of applications, it pays to do a little research and development from time time, reaching an uncertain hand out into the unknown to see what else is possible.
For the past couple days, I've become extremely "meta" with my research, building a PHP-based parser and MySQL database to analyze and store information about the PHP functions that operate the system. The initial idea was to analyze my code to see which of my functions used the most line of code, an analysis that had only recently become possible by virtue of a new string parser I'd written. But now, using the existing power of my own database visualization system, I could see a way to building a way to better visualize the actual code that runs it, thereby giving me the tools to visualize things I could have never visualized before. And how did I get here? Simply by disciplining myself to always write the most generic code possible through the development of a string of have been, essentially, utterly disposable/forgettable websites. When working on such projects, the crush of deadlines apply a toxic incentive to just write something that works and damn the future. But I've resisted that pressure, and the result has been a steady (and perhaps exponential) increase in my capabilities. Also, my work feels a lot less like drudgery than it would if I was just cranking out the same solutions to the same problems over and over and over and over again. Since my first job at CollegeClub.com, I've found that the key to software development happiness is to step back from the job, figure what fraction of it dull and unrewarding, and then spend some fraction of my time building tools to do that part automatically. That leaves a good fraction of my time for either research and development or just fucking around, activities I was never given sanction to do at any of my jobs.


For linking purposes this article's URL is:
http://asecular.com/blog.php?071216

feedback
previous | next