Chad Perrin: SOB

24 June 2006

throw two away: programming practice and incompatible APIs

Filed under: Geek,Metalog — apotheon @ 06:29

programming practice

In an entry at Chip’s Quips, Sterling discusses the various approaches to software development planning (or not) that have occupied him recently. From his presentation of others’ (un)common practices, I get this as a good way to handle things, complete with euphemistic jargon that could cover your arse (aka leverage a common contextual linguistic paradigm to enhance communicative synergy — “communicative” like a disease, that is):

  1. Prototyping! This is also known as the plan to throw one away[1] approach to programming — mostly depending on what audience you address. Call it “plan to throw one away” when talking to hackers, and “prototyping” when talking to bosses and clients.
  2. Requirements Phase! At this point, you spec out your project and expend some real effort in properly designing the software you’re going to write. That done, you write the application according to your plan. This takes advantage of the lessons learned from the head-first approach to programming taken in the prototyping phase.
  3. Refactoring! If you do it cleverly, you can basically rewrite the parts of the application that suffered from overdesign in the second phase, and everyone waiting on the final product will believe this is a necessary part of the process. Between the second and third phases, you’d do something you might call “beta testing”. This third phase should really be a rearchitecting of key parts of the system in most cases.

So: how do you get your boss(es) and/or client(s) to let you write the application three times — to use a throw two away development technique? Surely, they’ll throw a fit!

  • Do the prototyping in a “prototyping language”. This should consist of whatever language allows you to get the job done most quickly without worrying about maintainability by legions of mediocre code monkeys who will follow in your footsteps, and without worrying about whether anyone will ever approve your language for production code under current work circumstances, even if it’s a far better fit for the project than what they ultimately make you use in phases two and three. I can pretty much guarantee that if you do the prototyping phase in Common Lisp or Haskell nobody will ever try to tell you that you have to finish the project with the current prototype as your codebase, and you’ll be able to continue the project properly. Use a language that makes you happy and would scare the people you have to satisfy if they thought you intended to write the end-result production code in that language. Depending on how badly mired your “responsible parties” are, you may even get to use something as pedestrian as Ruby, Python, or Perl for prototyping. On the other hand, if they’re a little too savvy for that (but not savvy enough to let you just do it right without having to jump through all these hoops), you may have to go so far as to use Logo as your prototyping language. When they hear you used “that turtle language”, I’m sure they’ll demand a second development phase post-haste.
  • Pick out a couple of things that absolutely cannot be missing from the final product to satisfy the guys with the red pens, but that aren’t actually critical to a good, solid, working application. Work on them last. Beta test before those parts are tacked on. Tell them you’ll have to defer finalization of those features until the refactoring phase to ensure an integrated whole for the application. If you plan properly, everything you say will be true. Yay, you win.

Alternatively, if you have the sort of boss or client that likes to think (s)he is cutting-edge and hip to the New Thing, all avant-garde an’ stuff, you can just throw around phrases like “agile programming” and do the “iterative organic project evolution” thing. It’s a little like prototyping and refactoring beta testing and doing proper project design to varying degrees from day one to delivery. In fact, I think all this Agile Manifesto stuff is mostly a scam used to fool bosses and clients into letting programmers do their jobs properly for a change, rather than satisfying line-counting productivity monitors and using Hungarian Notation and Waterfall development methodologies. Free at last, free at last, thank Alan Turing almighty, we are free at last! (I guess that would make Ada Lovelace the Holy Mother figure in some warped variation on the Catholic model.)

Next step: getting the Ancient Unix Dork Neckbeard approved for corporate work environments (again). Don’t we all want to be the crazy, grizzled old mountain men of the computing world some day? I think we all look forward to the day we can say to our own personal version of Dilbert, in a patronizing tone, “Here’s a nickel, kid. Buy yourself a real computer.”

[1]: The full quote is, in fact, “Plan to throw one away; you will anyhow.” The source is a seminal work of software development madd ninja skillz, called The Mythical Man-Month. Go follow the link in the main body of the above text. If you’d done that in the first place, you wouldn’t have to read this rambling footnote at all.

incompatible APIs

I decided to finally get a tag cloud going on SOB. I don’t really think a tag cloud increases the usability of this site at all, but I’m sure it’ll help with search engine ranking. Because good ol’ Sterling has forged ahead in the world of site tagging, and even gone the extra mile by writing his own tag cloud widget for WordPress, I found that procrastination has again paid off in spades: the hard stuff has already been done for me.

I thought so, anyhow. I was wrong. There were some problems, which I’ll address in reverse order[2]:

  1. Like an idiot, I didn’t realize at first that Sterling’s widget needed to go in the widgets directory.
  2. Of course, at first I didn’t have a widgets directory.
  3. You see, the Sidebar Widgets plugin is actually incompatible with the theme I’m using, so I had to hack both the theme and the plugin to get them to fit each other.
  4. That, of course, was only once I realized that I needed the Sidebar Widgets plugin, since Sterling neglected to mention that in the readme.txt file that explains how installation of his (excellent) tag cloud sidebar widget works. Hint hint. If I had you in my IM contact list, I’m sure I would have mentioned this privately, Sterling. Hint hint.

Seriously, once I got everything shoehorned into place, I was suitably impressed. I like. One lesson that I had reinforced for me in the process, however, is that even with such simple software as WordPress sidebar widgets it is of critical importance to standardize, and stick to, a good API. As much as I like the appearance and general behavior characteristics of the theme I’m using (which I’ve hacked up quite a bit, but not enough to alter the API that allows it to interact with everything else — or, in some cases, prevents it from interacting, as with the Sidebar Widgets plugin), the nonstandard format of sidebar markup proved a notable annoyance in this case. It was worth the effort, though, in the long run.

[2]: I could have sworn there was a CSS property that allowed one to have ordered lists count backwards without having to resort to using number images as the list style type, or something absurd like that. If there isn’t, there darned well should be, and if there is, I’m going to feel pretty stupid for trying to do this when I haven’t slept for about twenty-four hours and later realize I missed something obvious. So what else is new?

and the tag cloud widget

Sterling — you rule, by the way. That widget really is pretty slick. Thanks.

By the way . . . did you intend for it to never linebreak in the middle of tag links in that cloud, or is that a carry-over from the way the Jerome’s Keywords plugin works? I’m considering changing that behavior, since I’m starting to have fun with long tag names, and don’t particularly intend the tag cloud as a useful navigation feature for anyone but search engine indexing spiders anyway.

7 Comments

  1. At first, I used an API from Jerome’s keywords to render the tag links. Later, I copied out part of that code because I wanted to cache the output. I preserved this little snippet: str_replace(' ', ' ', $key) That converts spaces in the tag to non-breaking spaces in the output.

    I suppose I should have mentioned that WordPress widgets require the Widget plugin, and that you have to use a theme that is widget-compatible (or modify your theme to be so).

    Glad you like the widget. I needed it for myself, but it has proven quite popular (96 downloads so far). As you noticed, it has the side-effect of creating a little link-farm right in your sidebar that masturbates your Google juice through the roof (can I say that?). I didn’t actually plan or anticipate that. I find the widget useful for myself when I want to hunt up an old post. I can remember what tags I put on it better than when I wrote it or what category I put it in or what terms to search for. The tags also make handy URLs to link to multiple posts on the same subject.

    Yeah, CSS for sidebars got really complicated with the widget API. Most themes apply styles across the entire sidebar when they should select specific sections instead. I had to modify the stylesheet for my theme to get the widget to work, and I’ve helped one other implementer overcome similar difficulties. Rule 1 for CSS: be as specific as you can sensibly be.

    Not so sure about prototyping in a different language. One of the benefits of prototyping is to find out what can and cannot be done, so if you have language or tools constraints on your final product then I think you need to do your prototyping with them.

    The third time around (which you labelled Refactoring) usually ends up for me being a total re-do from scratch in order to be successful, rendering the second version in effect a second prototype. Like your title says, throw two away.

    I like your second suggestion of holding back a key feature until the final version!

    Heh. I used to sport one of those “Ancient Unix Dork Neckbeards” back in the mid-80’s, when my primary development platform was CTIX (UNIX on a Convergent S-Series).

    Comment by SterlingCamden — 24 June 2006 @ 11:09

  2. Oh, BTW, you can GTalk me at chip dot camden.

    Comment by SterlingCamden — 24 June 2006 @ 11:13

  3. I updated the readme.txt file to indicate the prerequisites.

    Comment by SterlingCamden — 24 June 2006 @ 11:41

  4. Hey, thanks for the quick and helpful reply, Sterling!

    That converts spaces in the tag to non-breaking spaces in the output.

    Now, I won’t even have to decide what string to search for in the code, if I decide to allow linebreaks in the middle of tag cloud links. Thanks muchly.

    I suppose I should have mentioned [. . .] that you have to use a theme that is widget-compatible

    That’s not as critical, since the installation notes for the Sidebar Widgets plugin say something about that (I just didn’t realize it at first because I only skimmed the installation notes, silly me). Of course, I’m kinda glad I didn’t notice that at first, and didn’t know your widget required it at first, since it might have prompted me to look elsewhere for a tag cloud plugin — and in retrospect, I kind of enjoyed some of the process of getting my hands dirty.

    it has the side-effect of creating a little link-farm right in your sidebar that masturbates your Google juice through the roof (can I say that?).

    You can certainly say it here. While the image is a mite unfit for certain types of polite discussion, it’s effectively descriptive, and I’m by no means going to call the FCC to come fine you (or me).

    The tags also make handy URLs to link to multiple posts on the same subject.

    Yeah, I’ve got a tag or two like that myself. I’m still populating them with post references, though.

    Speaking of which — I’ve instructed my tag cloud to only display tags that refer to more than one post because I feel a little funny having “too big” a tag cloud on this thing, though nothing seems odd or wrong about the impressive size of your own tag cloud in comparison. I’m not sure why that is. There might be something in my psyche worth examining that prompts that sort of differing standard.

    I had to modify the stylesheet for my theme to get the widget to work,

    Oddly enough, I haven’t. The CSS has worked perfectly for it. What broke with my theme’s CSS was the sidebar display when I installed the Sidebar Widgets plugin itself. I’ve had to hack both PHP and CSS extensively just to get my sidebar so it doesn’t look like complete ass, and it’s still not as pretty as it used to be. I’ve given up on improving it for now, though — it’s “good enough” for the time being. Of course, I’ve been hacking the CSS for various bits of my theme almost since day one of running SOB, so this wasn’t as big a thing for me as it could have been, I suppose.

    The third time around (which you labelled Refactoring) usually ends up for me being a total re-do from scratch in order to be successful, rendering the second version in effect a second prototype. Like your title says, throw two away.

    Yeah, I didn’t really mean that it should be proper refactoring so much as that you might use the buzzword-compliant term “refactoring” as justification for the additional work before shipping when dealing with the Pointy Haird Bosses.

    you can GTalk me

    I’m unlikely, I think, to take up GTalk unless and until it becomes available for use via one or more of my available favored multiprotocol IM clients. I have long since given up loading up a separate client for a single IM service, unfortunately, though if I could use GTalk via Gaim or CenterICQ, I might be convinced to get an account with yet another IM service. C’est la vie.

    Now I have to get back to putting together that introductory PHP lesson I promised I’d create for someone. . . .

    Comment by apotheon — 24 June 2006 @ 01:19

  5. in a separate comment because I wanted it separate:

    I’m not so attached to my suggestions in this entry to this weblog that I’ll argue in favor of something like using a separate prototyping language very stridently. I do tend to think that using your actual implementation language for the second iteration pretty much covers the same-language prototyping need, so that it’s not so critical for the first iteration — and, just as learning a new language can give one new insights on programming, using a different language can give one different insights on the program on which one is currently working.

    It also probably helps to think of your first iteration in a separate language not as a prototype so much as executable pseudocode, or executable UML, or something like that. They say that when you use UML to spec out a project you shouldn’t get bogged down in the details: using a prototyping language lets you deal with implementation details while modeling the application, but also gives you a natural point of departure when writing the application in your implementation language while still having given you the better understanding of the problem that comes from actually speccing out the fine details of implementation to some extent. It’s sort of the best of both worlds. In fact, a couple of years ago, I wouldn’t have advocated “throwing one away” so much as “using a Turing complete programming language as your design-stage pseudocode”. It’s ultimately the same process, but it sounds good according to a slightly different “common wisdom” paradigm. I’m pretty good at euphemising for the ever-changing idiom, I think.

    This, of course, requires that you know both languages to some minimum level of competence as related to the complexity of the project, of course. That, in turn, requires me to use such an approach only for relatively simple projects, since my command of multiple languages suitable for, in alternate cases, prototyping and implementation is sketchy on my very best days. In fact, I don’t really know a single “best practices” common-case implementation language (think Java, C#, C++) well enough to tackle any project in this manner in stultifying corporate development environments: what development for pay I’ve done has all been web development and/or implemented with Perl thus far. As such, it’s entirely possible you know better than I do what is and is not a good idea for how to handle that first prototype.

    I find that I have, luckily, always been in a position where I managed my own development process, so I’ve been able to suit my initial plan to the task at hand, and let the development process itself evolve to suit the needs of a project. I’ve ended up doing some sort of hybrid between agile programming techniques and a throw two away methodology every time. On a couple of occasions, I’ve gotten something half-finished, then rewrote it in a different language because I had enough control over the process to change horses in midstream when I realized that my initial expectation for the best language for the job was egregiously wrong.

    I guess I’ve been kind of lucky that way.

    Comment by apotheon — 24 June 2006 @ 01:35

  6. Er, whoops, I spoke too soon. It looks like there’s Jabber support for GTalk, which means that Gaim supports it. Okay, okay, I’m all over it.

    Comment by apotheon — 24 June 2006 @ 01:46

  7. […] Chad came up with one idea: Alternatively, if you have the sort of boss or client that likes to think (s)he is cutting-edge and hip to the New Thing, all avant-garde an’ stuff, you can just throw around phrases like “agile programming” and do the “iterative organic project evolution” thing. It’s a little like prototyping and refactoring beta testing and doing proper project design to varying degrees from day one to delivery. […]

    Pingback by Labnotes » Blog Archive » Managing management — 25 June 2006 @ 04:30

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License