This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: I Killed A Risk Today, Oh Boy...
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
Actually, it was last week, but I tend to let things simmer before I blog them. It's more fun that way.
We're approaching launch of The Mobile Phone Project and, if things go according to at least one of several plans, there'll be a lot of people eventually hitting the website that promotes it. I mean a lot of people, and that's an interesting factor.
Last week, I was indulging in an hour's break from the head-down code/test/organize/phone/email cycle that's occupied me since the beginning of the month and trying to look at the big picture; to gain an overview of what needed to be done before we push the metaphorical Go Button[0]. What occurred to me was this: of the software that runs on the phone, there are some areas that are not as elegant as they should be; more complex than feels right. Not that they're badly written, or that they're flaky, or that they've caused tests to fail; no. But the reason they exist is to satisfy certain functional requirements that have been in the project since early on, and I found myself wondering if they're worth the extra risk.
Look at it this way; this is end-user, consumer technology. It runs on mobile phones, thus having it work simply, correctly and reliably is key. The extra bits of software add complexity. They interact with the phone and each other in ways that are not easy to test exhaustively (think of a network of co-operating processes and you'll get the idea). You and I, being programmers, both know, deep down, that's a source of extra risk. Now, if one in a hundred users has a problem, and we have a hundred users, that's not a heavy support issue. But what if we have a thousand? Ten thousand? Per month, or week? If risks are quantifiable (and a whole industry of risk management tends to argue that they are), these are small percentages. Yet when I multiply them by the big numbers of users, the end result is worrying. So I wrote a change request to remove functionality. To comment out, remove calls, unlink modules and simplify the whole thing. The code can go into version two, if there's a good commercial reason for it.
Was it wrong for the code to have ended up in there? Well, yes, from one point of view, because I've just written a change request (which costs effort and therefore money) to take it out. And no, from another. Each step towards the code was, at the time, reasonable. The need for the functionality was established, based on good commercial reasons. There were discussions about how to achieve it, solutions proposed and adopted, then turned into code. But at some point along the way, the code became self-sustaining. What I mean is, there was no questioning as to whether it was doing the right thing, just about how it should work.
I fell victim to this myself last week, in a tiny piece of Python code that handles the upload of data to the website and database, synchronizing the two. As part of this, images need to be processed in certain ways and, as a good Pythonista, I immediately wrote import PIL and started playing with the Python Imaging Library. Well, it started out as playing, and ended up as wrestling. Animated GIFs are a lot more complex than it might appear, especially when transparency and smallest-area-changed optimizations come into play, and the GIF reading code of PIL just... doesn't... work (with certain well-optimized GIFs). I spent three hours working through it, patching and testing, before a SIGALRM went off deep in the back of my head and pointed out that I was working hard at the wrong task. I'd become so caught up in how to solve the issue that was directly in front of me that I'd lost sight of the reason I was trying to achieve it, and thus all the different ways in which it could be done.
Half an hour later, the Python app was invoking command line apps like mogrify and gifsicle, letting them do the clever GIF stuff on temporary files that were sucked in and out of Python as required.
The English saying that best addresses all this is I can't see the wood for the trees. Hand me my axe, I'm a lumberjack today.
[0] Actually, I'm seriously considering having a real Go Button. I mean, making something live should be an event, right?
Previous Topic
