Found Software

Most of the software I write these days makes use of found software. Like the Dada art movement, I turn software I find on the internet into works that please me, and my clients. [ http://en.wikipedia.org/wiki/Found_object ]. This style is different I think than what is taught in CS and CE, where knowledge of algorithms, and BigO, are primary. The spectrum from original algorithm development to consumer product with large embedded software component is broad. In the strictest sense I focus on the need of my client, or my perception of their need and what might best address the gap. Rarely does the need start with a wholly novel algorithm. Thinking about it, the last time I developed such an algorithm may have been in 1992 for a CD-i compression scheme called DYUV where I enabled blits into the compressed data structure.
Recently my team has been working on a route generation package for UAVs. The constraint is it must be open software or developed in-house. People wanted to start in-house using standard A * search techniques. But we looked to see what was available – easy to do with Google. Looking for path finding I came across [ https://code.google.com/p/straightedge/  ]. A terrific place to start, it is in Java, it is BSD licensed, it has some nice visualization capabilities – always helpful for debugging. Now what is my software engineering point here? It is that we can probably save a great deal of effort by looking for found software that meets our needs but the task is not effort free, and in fact we may find that we go well down the path of using this software only to find some showstopper. My point is, I did not have to author an A * search algorithm, at most I need to know about it so I could work my Google search. What I do need is the long term experience of patching together various Java projects into a working cohesive structure that solves my clients’ problems. On a larger scale consider the software we will probably never have to write; an SQL data base (Postgres, MySQL, etc) a no-SQL DB (Couch, Mongo, Neo4j, etc), a fast messaging system (ZeroMQ, RabbitMQ, some other MQ d’ jour), your OS ( Linux, OpenBSD, even Darwin, and if you don’t like how it works the code is there to change :-) ). So being facile with many of these pieces helps, if you get stuck, being familiar with method of debugging is most important, and in making a large project being familiar with SCM and project architecture is most beneficial.

Leave a Reply

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