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):
- Prototyping! This is also known as the plan to throw one away 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.
- 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.
- 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.”
: 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.
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:
- Like an idiot, I didn’t realize at first that Sterling’s widget needed to go in the widgets directory.
- Of course, at first I didn’t have a widgets directory.
- 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.
- 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.
: 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.