Friday, January 14, 2005

Thoughts On Code Reuse

by Asim Jalis

When I first started programming for a living I had this vision that I would need to spend some time coding up useful libraries for the first few years and then I could make a living just by patching them together. I was eager to invest the hard work for a short period because I expected to reap a rich reward over a much longer period. Unfortunately, this optimistic scenario has not played out as I had expected. Invariably each project is different and reuse only occurs for trivial components. The only case where I see pervasive reuse is the Unix command line. And so this makes me think that the reason I do not experience as much reuse in my applications is because I somehow violate some of the core principles of Unix design. Instead of writing reusable applications that do one thing really well, I write reusable libraries. I shun applications that create multiple processes and string them together in pipes. Also I decompose my problems incorrectly. I decompose them into objects when I should be decomposing them into uni-functional applications. E.g. the GUI should not be a single object or a collection of objects, but rather it should be an application. According to Ward Cunningham, the solution to complexity is to solve one problem at a time. By solving the problem of conserving system resources (by using single processes) we unknowingly make it much harder to solve other much more important problems, such as code reuse and leverage. Compare Troff and TeX with Word and Acrobat. Which pair do you think will still be around in a couple of hundred years?