Death by radix

This post is reinforcement of a programming trap I should avoid in future, and punishment for selecting poor test cases. It’s not a bug of epic proportions, so move along if you have better things to laugh at than a bug in my Daily WTF-candidate code.

I threw together a simple booking calendar that uses a touch of JavaScript to make it a little more animated than a basic web form on cheapo PHP hosting. Part of the magic of this calendar is that it creates a string of the form “Your booking is for one night from Wednesday July 13th 2011, departing Thursday July 14th 2011” to help reinforce to the user that the correct dates have been understood by the booking system.

When I implemented this booking calendar it appeared to work nicely. Nonetheless, I wrote test cases for it. When there were plenty of tests and they all passed I was feeling smug that my JavaScript was probably provably better quality than most of the JavaScript in existence given it had tests.

It operated for a few months with no complaint. Then there were several reports in one week that the code wasn’t generating the correct weekday.

“Inconceivable!” I thought.

I tried it myself with the dates users complained about and found it was generating crazy weekdays. I checked, and my regression tests were passing just fine. I then plugged the reported problem dates into my test suite. My old test cases succeeded and the new ones failed.

So, down to diagnosis.

The “bulk” of the code is pulling the date string apart so I can use date-related utility functions. The problem was my use of parseInt().  

parseInt() parses a string and returns an integer. I discovered that it works fine for some months (01, 02, 03, 04, 05, 06, 07, 10, 11, & 12) and not for 08 and 09. This is because parseInt() assumes that if the string it is parsing begins with a 0, then it’s an octal number. That works for 01-07 because they generate the same number whether you parse them as octal or not. 11 and 12 work because parseInt() correctly guesses that they are base 10. 08 and 09 are automatically detected as octal, but they fail to parse as octal numbers. I used the error return value to populate the month in a Date object which dutifully interpreted the value as December. The weekdays were right… for December.

Sure enough, none of my test data contained a date in August or September.

The main fix is that the parseInt() function takes a second optional argument that sets the radix to use and stops it from guessing.

I’m still trying to think of a situation when you might want parseInt() to guess the radix for you.

Improved boot times: Vista vs Windows 7

I think it was Andrew who pointed me to Soluto as a method of improving boot times on Windows PCs.

I have mentioned before that my Vista-running X61 tablet takes a while to boot. Soluto measured boot time at just over 10 minutes. I followed its advice, and through delaying and removing various crapware and legitimate startup programs I got boot time down to 5 minutes and 10 seconds.

Emboldened, this weekend I took some advice from Ian’s comments on my last post and shelled out AU$300 for a copy of Windows 7 Professional (upgrade).

Now, with a few tweaks recommended by Soluto I’m recording a consistent boot time of 1 minute 35 seconds.

My aging tablet feels like new again (during boot).

Update: Actually, it feels pretty snappy since the Windows 7 makeover and some hybrid SSD drive loving. Boot time is now a shade under a minute and application launches are snappier than they’ve ever been.

A short review of Adobe Soundbooth CS4

It crashes a lot.

I’ve been using Soundbooth to clean up speech from about 10 people recorded in a conference room, on a tiny digital recorder, while it sat next to a projector’s fan, under an air-conditioning outlet, in a slightly echoey conference room, open to a common area where people gather to take the elevator.

Cleaning up the audio was a reasonably fast, if crashy, experience.

Once I had a reasonably clean recording I thought I’d try out the automatic transcription feature. This feature performs some cursory speech recognition on an audio file to produce tags that match recognised words to their location in the audio file along with the speaker’s identity (e.g. speaker 2). As it’s only 75% accurate (for my samples, forgivably, it was much worse) it’s more useful for finding points of interest in an audio file than as an auto-transcription service.

I don’t think it ever completed the transcription task. At some random point it would offer to send Adobe a copy of a crash report.

Though it doesn’t have transcription capabilities, I think I prefer Audacity.

Levelling up

Tomorrow, December 5th 2008, marks the 20th anniversary of my starting work in “the industry.”

This calls for five minutes of reminiscing.

I turned up for my first day of work as a trainee systems programmer at a big Australian bank’s EDP department. I recall being more than a little shocked at having to be at work before 8:06am each day. I was introduced to everyone I’d be working with shortly before being sent off to North Sydney to do MVS and IBM System/360 Assembler training for a few weeks.

At training I learned that the most powerful instruction in Assembly language was the no-op. The coding standard dictated that you sprinkle them throughout your code so that smarter programmers than you could patch your code, in memory, while running by overwriting your no-ops with useful code and then adding a statement to branch to the patch code over the defective instructions.

The bank had some great people. Some were consummate professionals and some were real cowboys.

Towards the end of my time at the bank I was introduced to the pointy-end of the economics of software development and process improvement.

A colleague returned from a long liquid lunch and let me in on the “big secret.”

He said only fools write good code. Code has to break for you to get called in. Being called in gives you overtime and visibility. Overtime is extra money. Being called in is heroism. Develop skill in writing bugs that are serious enough to call you in about, yet easy enough to fix soon after you get into the office. Overtime was paid for in four hour minimum units. Nobody notices people who write reliable code because they never get to perform heroic acts. Notice that the people who get promoted are those that handle high stress situations. Notice that the people handling these high stress situations are generally responsible for creating the high stress situation in the first place.

It was good motivation to find a new job.

iPhone application idea

Regrettably, I don’t have an iPhone. I do, however, have iPhone envy. I can tell, because I have dreams about accelerometers and iPhone apps I’d like. Also, I have nightmares about dropping my imaginary iPhone.

Given I don’t have the necessary equipment to develop an iPhone application, I hereby give you, The Internet, my idea for an iPhone application. My envy-inspired dreams have resulted in an idea for an App whose sole purpose is to add a little levity to those near-miss moments when you think you’ve accidentally destroyed your iPhone.

My imaginary app patiently waits for the accelerometer to report extreme acceleration events, such as when the phone has fallen to the ground. Shortly after the high-G event, the app plays an audio file that says “Well that was close!”

That’s it.

No additional logic is required for the case when the G force is so great the iPhone stops working. Those moments are best kept levity-free.

Tablets, Tablet PCs and software development

For a long time I thought that if I were better able to quickly construct illuminating diagrams to make a point or communicate a concept then I’d be a much more effective communicator. Effective communication is a boon to software development, so improving my ability to rapidly pump out neat diagrams was a noble goal worthy of investment.

I thought that if I had a tablet I’d be able to pick up any drawing package and quickly render those few boxes, circles, arrows, classes, use-cases and swimlanes with a pen in double-quick time. Surely a pen is the natural way to draw, and therefore faster and easier.

I had my eye on a Wacom tablet for a while. I had used a few casually and found them awkward. Designer friends told me that it takes some getting used to and a rigour about the way you set up and use applications. I had also worked with a UK-based engineer who used one for illustrating and annotating shared applications, presentations and documents during design collaboration conference calls. I was convinced my first impressions were wrong.

“Cool” I thought. “Let the tablet-led communication-effectiveness and R&D begin!”

After I saw that Julian had a tablet, I abandoned rational thought and cool-headed evaluation while toy envy took over. I dropped about AU$100 on a cheap Wacom-like tablet to figure out if it was a worthwhile addition to my professional and home-tinkering life.

After getting used to looking at the screen and not the tablet, and making the mental switch from mouse-relative pointing to tablet-absolute positioning seem relatively natural I worked on using a few applications.

In a week or so of trial use I came to the following conclusions:

  • EverNote is way cool for doing shape-drawing, but I was still about half as fast at constructing diagrams with the tablet as using a mouse and keyboard. I also made lots of mistakes with the tablet that were kind of painful to correct. I wish more applications had EverNote’s (and the Apple Newton’s) shape recognition/fixup mode.
  • Visio is kind of awkward with a mouse, and even more awkward with a pen.
  • Few applications have big enough icons that can also be positioned conveniently enough for tablet use.
  • Unsurprisingly, the best applications are painting programs like Photoshop and Paint Shop Pro. Primarily it’s because with a tablet the curve you render on the tablet is the curve you see on the screen. With a mouse, you have to convince your body to implement a kind of feedback and control system to modify your physical action to produce the curve you want to render.
  • Tablets are cruel and frustrating.

I gave up on the Wacom-style tablet, though I’m not sure that I gave it a fighting chance. I got to a point where my frustration was greater than the residual value of my AU$100 investment and abandoned it.

Time passed… and the opportunity to get a tablet PC at less than extortionate prices presented itself. Quite apart from the X61 being a tablet PC, it’s far more portable and usable than any laptop I’ve owned since my Mac PowerBook 170.

In summary, in the contest between tablets and tablet PCs, tablet PCs win.

Direct manipulation of screen pixels is much more approachable than separate tablet hardware. They’re more portable, convenient for more applications and they don’t get your colleagues confused about whether you’re a graphic designer or a developer.

That’s not to say tablet PCs are the perfect tool for diagramming.

Bear with me while I offer some completely un-benchmarked productivity estimates.

When it comes to drawing diagrams with perfect boxes and lines in an application like Illustrator or Visio, I’m about 20% faster with a mouse. If the requirement is for nicely typed text, then the mouse and keyboard wins by about 50% over the tablet PC.

But there’s a diagramming mode where the tablet PC shines: freehand diagrams.

If the boxes, lines and arrows don’t need to be perfect, and if the text is handwritten, and if the diagram won’t need to be maintained, then drawing freehand using OneNote or EverNote on the tablet PC is probably 50% faster than using a keyboard and mouse.

After recognising this my primary use of the pen mode on my X61 Tablet has settled into these tasks:

  • Quick and dirty diagrams to capture notes or communicate information, often projected on a meeting room display or web conference, and sometimes to be later transcribed into a “proper” UML tool or Visio.
  • Annotation of documents, spreadsheets and presentations with Office 2007’s pen reviews.
  • Note-taking & annotation of typed notes.
  • Painting.

For me personally, the dream of being able to use any illustration package more effectively with some kind of tablet is gone, yet note-taking with freehand illustrations is something I now find indispensable.

Taking the plunge: Windows Vista Service Pack 1

Every patch on my X61 tablet seems to bring Vista closer to the nimble responsive OS I’d like on my quasi-mobile PC that isn’t a Mac.  Today I noted on (Ars Technica) that Vista patch nirvana had arrived: SP1.

Installing Vista SP1

It’s not kidding either.  It was 1 hour and 20 minutes later that it declared Windows Vista SP1 installed on my tablet.  Thankfully no intervention is required during that time.

Now fingers crossed that not waiting for the Windows Update push in mid-April will spare me an NT 4.0 service-pack-like experience. 

So far I can report an overwhelming sense of sameness.  It’s quiet.  Too quiet.

Update:…and it boots and comes out of sleep faster.

Soporific Manifesto 2008

Once upon a time in 2002 or 2003, Mr Ed asked me if I had any interest in writing an essay for a new web site he was thinking of setting up called HackNot!  I had a bunch of mostly sardonic and simple thoughts in a file somewhere and I sent it off to him asking if this was the kind of thing he was after.  He relied yes, and I duly got busy with something else and evaded towards completing it. 

I think Ed grew tired of waiting for me and edited my incoherent rambling into an ordered list and plugged it up into public view. 

I thought that now, nearly 5 years later, would be a good time to re-examine some of those thoughts.  I’m way kindler, way gentler, and way more verbose now.  The process of looking at what I thought 5 years ago is bound to ignite a flame war with myself.

I’ve taken a copy of the HackNot! article and added notes along the way.

In 1995 the Unabomber’s manifesto was published in The New York Times. In 2001 the Agile Alliance published their Agile Manifesto. Now our own Tedious Soporific gets in on the act. His personal manifesto leaves no area of software development untouched – from the hazards of frameworks to the role of “doof doof” music in requirements elicitation, it’s all here. Truly a heartbreaking work of staggering genius.

Heartbreaking and staggering but not genius.


  • Humans read requirements.
  • Humans lose interest if they can’t understand the requirement, or why it’s there.
  • Requirements numbers should never contain the section number of the document they are in.
  • A requirement only needs to require an implementation in rare circumstances when you need to require a point of concrete integration(shall run inside IE 4.0 and up etc.)
  • Requirements should be able to be tested. If you write a requirement that may be hard to test, write supporting notes about how you would envisage the requirement will be tested.

This is a bit of a crude list of things that have irked me about requirements in the past.  I would say, without fail, that poorly written, or conceived, requirements cause me the most pain in my work.  Both reading other peoples’ and re-reading my own hastily-prepared requirements can be a trial.  These days I think I would just point to Carl Weigers’ two excellent texts and leave it at that.

According to Capers-Jones, best practice is to spend 10% of a “systems” software development project’s effort on systems engineering.

  • User interfaces are design, not requirements.
  • Track requirements met during development by mapping requirement coverage to test results.

I stand by my statement, but the reason it’s a manifesto entry is that UI design is not a requirements generation activity.  It’s a design activity, and a vitally important one.

One of the most interesting diagrams about the importance of user interface design and its relationship to estimation I’ve seen is on page 39 of Steve McConnell’s “Software Estimation: Demystifying the Black Art” (see a spreadsheet I prepared earlier here) where he discusses the cone of uncertainty.  This diagram is about the variability in estimates done as a project progresses. 

Before “product definition” a project may take from one quarter to four times the time estimated at this point.  Estimations done at the time detailed requirements are available take the likely variability ranges from two thirds to one and a half times estimates done at this time.  The next step is user interface design.  When the UI is designed, the likely variation from estimates done at this time are from 0.8x the estimate to 1.25x.  If you’re not doing a UI design and re-estimating at each milestone of project definition, you’re not interested in estimates.

I’d go further than tracking requirements to tests and say that requirements should be mapped to architecture and design so the relationship between design decisions and requirements is obvious to developers and archaeologists who look upon your project in later years. 

  • Because a customer asks for a feature to be implemented, that alone doesn’t make it a good feature.
  • Moral time: A man walks into a hospital having already diagnosed himself with prostate cancer. He demands that a surgeon operate immediately to remove the cancer. The surgeon operates. The man is caused inconvenience, discomfort and pain for the rest of his life from side-effects of the operation. The surgeon could have refused to operate, citing that 80% of men die with, and not because of, prostate cancer. The surgeon gave the man what he asked for and not what he needed.

What a smarmy bastard I was.

A simpler way of putting this is that the job of a software professional is to tell your customer when they’re asking you to do something they shouldn’t do.  Sure, they can go ahead and do whatever the silly thing is anyway, but you shouldn’t really let someone demand that your team build a content management system when there are free and commercial versions out there that may meet your customers’ needs.  Customers tend to talk about how the system should look, so it’s easy to fall down a rabbit-hole of having the customer design everything for you.  If you are mindlessly implementing everything your customer tells you to, you’re somewhere in the spectrum of working with a very capable customer to not behaving as a professional software developer.

  • Q: What can you brush your teeth with, sit on, and telephone people with?
    A: A toothbrush, a chair and a telephone.

This is a bit too subtle and clever, which contradicts something else in the manifesto (see below).  I advocate looking at the problem to see if you’re solving one problem or several.  Consider if it’s really appropriate to solve two or three distinct problems with one development or a monolithic product.  Any way a project can be made smaller, or divided up into several projects is advantageous.  In software we have know from Barry Boehm’s work that there is a diseconomy of scale of software development, so three small projects have a much greater chance of succeeding and coming in near to time than one big project does.


  • Specify performance early.
  • Optimise late.

Specify performance requirements as early as you can and realistically.  If you find your customer pulling very ambitious figures out of thin air, mark the performance requirement for later.  If you find there is hard and believable data behind the performance requirement, then you should note the source and breathe easy that the performance requirement is believable.

Optimising late is a reaction to developers who get carried away making code perfect up front.  If you have a believable performance requirement that is unprecedented then you should see this as a project risk and consider prototyping, benchmarking and discovering early if your project needs to be sent to an early grave for being infeasible before you spend a lot of money and reputation on something impossible.  Pay attention to performance and don’t optimize things that aren’t a bottleneck or won’t help you meet your project goals. 


  • Styles in Microsoft Word are your friend. If you want a Word processor, use Word. If you want a typewriter, use Notepad.

There are many things that may be reused in software development.  Documents are one of the most commonly reused development artifacts.  If you use Word to do your documentation, learn about styles, automation, cross-references, footnotes, and keep your source material close to the document and in source control.  Don’t be too proud to go on a Word course – if you’re tabbing, or double-entering to get paragraph markers please go on a course. 


  • Beware the “framework.”

Perhaps this should read “Beware the project with no end and no clear customer” as this entry was about projects that allow themselves the luxury to think that everyone wants what they’re producing they just don’t know it yet.  I’m sure many successful frameworks came from over-resourced projects with an ambition to meet requirements they just invented for customers that “don’t even exist yet” but I’m also sure there’s a 20:1 ratio of failures to modestly successful frameworks born from over-generous budget allocation.

  • Spurn the “reusable component.”

Reuse was big at the end of the 90’s, resurfaced as Product Line Engineering in the early 00’s and seems to have died down prior to resurfacing as SOA around about now.  I’ve written before about how I think that design, experience and plain-old code-stealing are some of the most effective forms of reuse.  Backed by tools that support findability and developer communication, code reuse will blossom in an organization.  Building a repository of carefully curated reusable components and controlling their use and limiting their mutations is intended to reduce testing requirements and defect propagation, but it also stifles innovation and discourages reuse.

  • It’s hard to specify a framework because what users might require rarely becomes what they’ll need for sure: “You ain’t gonna need it.” Your customer wants to pay for a solution for their problem, not everyone else’s.

Would you like to be a customer who wanted to pay for an SQL query and got an ORM framework for only twice the price?


  • XML: it’s just a verbose way of representing structured data.
  • SIP: it’s just a signalling protocol.

The road to hell is paved with overreaching hyperbole about the potential of new technologies.  Both XML and SIP are useful technologies; both brilliant and compromised.  Before them was WAP, Token-Ring, OpenDoc and a lot of other promising technology that was way over-hyped. 


Most projects have version two of a product loaded up with features a long time before version 1.0 has been seen by customers.  The absolute best resource for requirements is customers, and their best ideas don’t come in focus groups or interviews about the problems they have.  Customers’ best ideas come when they’ve seen version 1.0 and hate it enough to tell you what they’d really like.  If the next release is already full of requirements that are sourced from marketing or product management, customers will be upset with 2.0 as well.  If you can’t make them happy with release 1.0, make them happy the second time they see a release.  Customers you listen to become your ally and make marketing a whole lot easier.

  • When someone says “I know this is a death march, but you will be rewarded well if you succeed or fail,” run (away) like the wind.

This was a lie told to me once.  Use the experience to remain as professional as you can, or run.


  • Habitable development environments.

This was a placeholder for something I read once and could never find again.  The idea is that, like share accommodation, teams need to find their level of process and code hygiene.  Some brilliant developers work with little infrastructure and formality and others work best with lots of structure.  When building a team consider what each developer finds habitable and make sure you get a team that can accept the coding standards, process rigour and meeting load that you intend to inflict on them.  In a share house, some people like to leave the dishes until there’s a good pile, others like to wash everything on a regular basis.  If you have lived with people at either end of the cleanliness and habitability spectrum, you know how important this can be.

  • Give directives in positive terms.
  • Avoid saying what shouldn’t be done.
  • Toddlers and software engineers want to please you, and do the right thing.
  • Toddlers and software engineers hear “Don’t do X” and become paralysed with uncertainty because they now know for sure what they shouldn’t do,but can’t figure out what you do want them to do.

How patronising!  It’s a subtle message. 

If you want people to change, tell them what the outcome should look like in terms they understand.  If an executive stands up and says “don’t be evil,” your expectation is that you can go right up to the line, lean over and smell the sulphur, and still be in the clear.  If your executive says “from now on we’re not a services company” middle management might set about firing your services staff with no vision for what you really want to be. 

User Interfaces

  • Usable interfaces should not be innovative. If it’s clever or tricky,then it’s probably confusing.
  • Users don’t use the right mouse button.

Let’s back off to saying that you can’t expect users to rely on the right mouse button.  Watch some regular users use applications sometime. 

  • It’s hard to know when to double-click unless someone shows you.

Watch some users sometime.  A lot of older users double-click hyperlinks because someone once showed them that the way you get a computer to respond to you was to double-click.

  • Users don’t use tree views. Users don’t get trees.
  • Users only (very) rarely see trees on computers.
  • Developers love tree-views.
  • DevStudio [and Eclipse have] trees.
  • Windows file explorer shows a tree.
  • Most users never see or use tree-views when they’re using Windows (or Macs) and don’t find them comfortable.
  • Think about where the Windows explorer is located in the Start-> menu(it’s an “Accessory”) and where the “My Computer” icon is (on theDesktop) and what happens when you double-click it.
  • You have to configure Outlook to show a tree view of your folders on the left.
  • Standard Windows application file (save/open) dialog does not show a tree.
  • A tree is not an easy metaphor. When was the last time you saw a real live tree of folders?

I guess I was tired of seeing lots of new applications that looked just like the IDEs used to build them.  The tree has thankfully been supplanted by the Google-like search & results list. 


  • It’s hard to write requirements unless you’re ears are being pounded by”doof doof” music.

Actually “doof doof, chikka, doof doof” music is better, I’ve found.

  • Unfinished Sympathy is the finest pop song ever written.

I have to revise this one day.  But the combination of serious-sounding nonsense lyrics, orchestral pomp and an addicting hook make it hard to beat.

  • “Refactoring” is not synonymous with “fixing bugs”.

Like the XML and SIP thing, this was written at a time when the term was overused.  “I’m going to refactor that bug report” or “I’m going to refactor my performance problems” were not uncommon.

I’ll follow up later with “Epiphanies about software” posts, but I think I’m done with manifestos.

When iTunes iAttacks

Today I updated my iTunes software to version 7.6 on Windows XP and Vista, hoping to see if I could rent “300” and play it, and get an idea of whether I liked the whole rental idea. Sadly, though I can play music fine, iTunes 7.6 doesn’t want to play audio from my TV Shows or Movies anymore.

This “no sound” experience happens on both my Vista and XP machines.

US$3.99 down the drain, and only 30 days left to rescue my movie hire.

I’m baffled. One more gripe to add to the list.

Windows Live Writer

I’ve been using Windows Live Writer for the last couple of posts.  If you’re looking for WYSIWYG editing on WordPress, I can recommend it. 

Live Writer grocks your site’s styles (I doubt it can handle coded style extensions, though) so you can get a pretty accurate preview before you post.  It automatically handles image uploads, categories, gives you buttons to access the dashboard and comments management and produces pretty spare markup.  I haven’t used the video options or any of the other options, but I can acknowledge they’re there. 

It even allows me to gratuitously show off my new toy with…

In all, Live Writer has proven to be a very pleasant offline blog editor.  Between OneNote and Live Writer, I’m in danger of becoming a Microsoft fanboy!