Engineered vs. Organic Code
The code I posted this morning is nothing I'd ever show to a prospective employer. It is sparsely commented, convoluted, and nearly impossible to expand. All I actually wrote of it last night was the part to prune down the source tree, so that the best-rated categories weren't being spammed out by a bunch of one-hit wonders while leaving good bands with average ratings in the dirt because of unrated songs. It was probably about 1k of new code, but it took nearly six hours to do. Half of those were just getting into the headspace required to understand the rest of the code, which was from sometime before last Christmas.
That code is organic code, in a nearly pure form. I sat down one day saying "I want to solve this problem, and as the sole owner responsible for this problem, I am willing to bear the risk that the resultant code will be oddly organized, difficult to expand, and probably incomprehensible to anyone who isn't me right now." Then I sat down and wrote, and knew it was time to stop when it stopped being easy to write.
If you look at the code as presented, I generate a complex, highly-interconnected data structure which perfectly represents the structure of my music library but is actually not so great for generating interesting statistics about it. I knew last night, once I had figured out how things worked but before I had actually started writing anything new, that I could probably have gotten the end results I wanted faster by scrapping everything. Throwing the data into an in-memory sqlite database, interfaced through SQLObject, would have made the problem of actually finding the relevant information trivial.
I chose not to do that, instead kludging a pruning system together that, though not particularly efficient, worked within the existing paradigm. Why'd I make that choice? I know full well what good software engineering is like, and how to do it. It must, therefore, have been a choice.
Engineered software is modular, expandable, full of interchangeable components which use well-defined interfaces. It's not all that difficult: simply stating the problem properly implies the solution, which may be complex or broad, but is rarely actually difficult. For a problem like extracting statistics from my iTunes track ratings, it takes only seconds to see how to do it, but in order to see any results you have to put in an hour or two of implementation which is pure boredom.
Organic software, on the other hand, just sort of grows into place, channeled into a certain design more through the accidents of iterative bug fixing than through any sort of pattern. You get to skip all the planning and jump directly into implementation, which invariably leads to a long sequence of ever-less-plausible logic puzzles which must be solved. Eventually, everything is in place, and you have a Rube Goldbergian contraption in code which may or may not work properly. You flip the switch and see it chug along and it either explodes spectacularly or somehow produces the expected results. In the first, more common case, you are now faced with a new logic puzzle. In the latter, you've won, as the work is now complete.
That whole process is a surprising amount of fun. When it comes right down to it, I don't need or really care about knowing these statistics. However, the process of discovering them was enjoyable. Like the guy who built a steam-powered walking robot, the point isn't really to produce a viable mode of transportation. It's to enjoy the building of the thing.
That code is organic code, in a nearly pure form. I sat down one day saying "I want to solve this problem, and as the sole owner responsible for this problem, I am willing to bear the risk that the resultant code will be oddly organized, difficult to expand, and probably incomprehensible to anyone who isn't me right now." Then I sat down and wrote, and knew it was time to stop when it stopped being easy to write.
If you look at the code as presented, I generate a complex, highly-interconnected data structure which perfectly represents the structure of my music library but is actually not so great for generating interesting statistics about it. I knew last night, once I had figured out how things worked but before I had actually started writing anything new, that I could probably have gotten the end results I wanted faster by scrapping everything. Throwing the data into an in-memory sqlite database, interfaced through SQLObject, would have made the problem of actually finding the relevant information trivial.
I chose not to do that, instead kludging a pruning system together that, though not particularly efficient, worked within the existing paradigm. Why'd I make that choice? I know full well what good software engineering is like, and how to do it. It must, therefore, have been a choice.
Engineered software is modular, expandable, full of interchangeable components which use well-defined interfaces. It's not all that difficult: simply stating the problem properly implies the solution, which may be complex or broad, but is rarely actually difficult. For a problem like extracting statistics from my iTunes track ratings, it takes only seconds to see how to do it, but in order to see any results you have to put in an hour or two of implementation which is pure boredom.
Organic software, on the other hand, just sort of grows into place, channeled into a certain design more through the accidents of iterative bug fixing than through any sort of pattern. You get to skip all the planning and jump directly into implementation, which invariably leads to a long sequence of ever-less-plausible logic puzzles which must be solved. Eventually, everything is in place, and you have a Rube Goldbergian contraption in code which may or may not work properly. You flip the switch and see it chug along and it either explodes spectacularly or somehow produces the expected results. In the first, more common case, you are now faced with a new logic puzzle. In the latter, you've won, as the work is now complete.
That whole process is a surprising amount of fun. When it comes right down to it, I don't need or really care about knowing these statistics. However, the process of discovering them was enjoyable. Like the guy who built a steam-powered walking robot, the point isn't really to produce a viable mode of transportation. It's to enjoy the building of the thing.