Tuesday, July 15, 2008

Organic Code Development

I always find it amusing how some of my best coding happens so organically. That is to say, there is no true overarching design usually, just an end goal. Take for instance, my latest creation. I've been working on adding support for wind barbs to the python plotting library matplotlib . I initially tried to design it well, think about where the natural breaks in the code would be and then just build these smaller pieces. This worked for some of the simple things, but in the complexities of figuring out transformations and coordinate systems, it got to be a real bear to work top down. Perhaps things like stub functions and other mock objects might have been able to help here, but that's beyond my software development skill set at the moment.


So out went that approach, and I started with the simple goal of getting a single barb to appear on the plot, using the most direct and manual way possible. Once that was achieved, I added a couple more to the test and made sure that they scaled right, and were positioned properly. From here then some refactoring occurred and things were broken into more logical groups, and manual hard coded things were replaced with more flexible (and arguably) simple code. Here's the (more or less) final result.



I now have 320 lines of commented and documented code ("borrowing" a lot of the documentation and input processing from a similar matplotlib function, quiver). I'm just amused that this kind of procedure always seems to work better for me. I was stuck for days trying to get this working, trying to figure out where to begin. It was so much easier to start with a simple, small goal and build on it. Then again, this might work better for me because I'm a scientist who codes rather than a software engineer/developer. It could also be because every time I do something like this, I'm learning a new API or even an entirely new library. Maybe if I finally developed a deep expertise with something, I might be able to think at a slightly higher level....nah. :)


I think I've really only ever succeeded in designing and implementing one project, my radar emulator . While it turned out well, it's not a design that at this point I'm in love with (though I'm stuck with it at this point). Then again, I started that in 2003, when I was far less experienced. Another project I've been kicking around in my head forever, a simple data visualization program, is persistently stuck in the design phase. Granted, it's predecessor grew organically and became unwieldy, but that was C++, where refactoring is a nightmare. But it did have the benefit of actually existing in code and being (somewhat) useful, which is more than I can say for an idea floating around in my head.

Anyhow, less rambling, more code! On to Skew-T's!

No comments: