Recovered from the Wayback Machine.
This last week I’ve been heavily into development, trying to get OsCommerce to agree to operate a certain way, in addition to doing some really strange things to the version of WordPress in use at Bb (changes which will then get ported to Wordform). In fact, you may see things break here and there, off and on, as I’ve decided to do all my coding ‘live’ — directly to my working weblogs.
This is contrary to traditional development practices. Normally the rule is to code in a separate space and then roll out a nicely polished, tested, finished, fairly stable working copy. However, I thought it might be interesting for non-technologists to see what an application looks like as it undergoes changes.
I sometimes think we, the techs, hide what goes on behind the scenes too much–fostering a myth that an application is solid-state when really its bits and pieces stuck together. Hopefully, we manage to stick the bits together in a way that they actually do something useful, but that’s not always the case.
It’s frustrating for users to hit a bug in software, and when they do, they wonder how this bug could be missed and/or why isn’t the developer just “…putting out a quick fix”. What happens, though, with many bugs, is that trying to fix the code in one spot can break it in three other places because the code is really bits and pieces, stuck together in a way that hopefully works, but in this case, doesn’t.
It then becomes equally frustrating for the developer to try to explain to the user that there are so many moving parts to an application of any size, there is no such thing as ‘bug free’ code. In addition, the ‘quick fix’ the user asks for could take a month of developer time because it’s connected to half a dozen other bits of code all of which need to be changed–so they shouldn’t hold their breath.
For the next month, as I work at creating all sorts of new goodies (for WordPress, Wordform, and other weblogging tools), you can watch me break, repair, break, and then repair again my own weblog installations; all the while comfortably knowing its my site, my weblogs, my code that’s falling apart, not yours. Sort of like you being an observer behind one-way glass, and me being the insane patient under treatment.
Speaking of coding on the hoof, you saw it here first: iProngs and prodcasting.