The Benefits of Unpredictable Reuse
by Simon St. Laurent
Good computing practices frequently lead to easily reusable data and code. Reuse isn't always a priority, and you can't always see it coming, but it makes the work that's done far more valuable than can be expressed in return on investment for a particular project.
I've spent a lot of this weekend writing unit test code for routines I wrote two years ago. I wrote the code to be reusable in a classic object-inheritance kind of way, but at the time I had very little clue about what I could do to make that code a solid foundation for other work. Sure, I've cut-and-pasted routines, adapted code to new needs, and done what I could to make the code readable years later, but creating code structures designed for modification was way beyond me. After a weekend writing a library of tests, I feel like I'm finally figuring how to write code that can be reused and repurposed without dire paranoia and dense fog.
At the same time, I'm planning to reuse some XML data I had created for one set of projects in a completely different area. Data points for an XSLT-generated SVG map are suddenly going to be fodder for statistical analysis in Excel. I didn't spend an enormous amount of time building the structures early on, but maintaining the basic content/presentation divide was enough to keep the data reusable. (Relational databases offer many of the same advantages to developers who focus on how to normalize their data rather than thinking only about the task they want accomplished today.)
There may not be much initial benefit to spending time building unit tests and producing clear XML vocabularies (rather than just object or table dumps), but both of these practices make it much easier to deal with that programmer's nightmare: change.
At the start of a project - or even at the end of a project - there's no way to know how much value someone you may never meet will derive from the effort you put into making your code and your data robustly reusable. You or your organization may be the beneficiary, if you're lucky. If you're even luckier, you'll benefit from the work someone else put in.
All this extra work... why can't I just use undocumented one-letter variable and element names?
Why is Change a Nightmare?
I write the simplest code that could possibly work and let the tests drive my development for the same reason that I (fully intend to) clean up my kitchen after I cook.