The Daily Kibitz

Some ideas for programmer metrics

2010-07-27T17:52:00.000-07:00

Lines of code is a terrible metric of programmer productivity, prone to all sorts of gaming of the system, and here's a great story to illustrate: -2000 lines of code (+ some nice discussion). Bill Atkinson ends up subverting the simplistic management by entering -2000 under the lines of code box, signifying the net number of lines he contributed during the week.

Of course, what this didn't capture was the qualitative detail of his work: identifying bugs, deleting, adding, fixing, abstracting, simplifying. No single number can capture that.

Indeed, the great W Edwards Deming warned -- but who takes notice? -- that taking any measure (simple or complex) and rewarding or punishing according to it is asking to be gamed. Doing so made #3 in his list of seven deadly diseases:

1. Lack of constancy of purpose
2. Emphasis on short-term profits
3. Evaluation by performance, merit rating, or annual review of performance
4. Mobility of management
5. Running a company on visible figures alone
6. Excessive medical costs
7. Excessive costs of warranty, fueled by lawyers who work for contingency fees

That said, it's not to say that metrics can't be useful as a source of insight. I wonder whether a simple multi-dimensional metric on lines-of-code could be helpful.

Suggestion:

1. Lines of own code added
2. Lines of own code deleted
3. Lines of others' code added
4. Lines of others' code deleted
5. Lines of code deleted by others

I envisage that collecting this kind of data on a weekly basis (say) could show interesting patterns for individuals over time, and corroborate gut feelings about who is refactoring vs adding functionality vs breaking stuff etc.

Another aspect to consider is the scope of these metrics. Does one measure individuals, pairs, or whole teams? If the metrics were implemented for the whole team as a means of self-assessment changes over time could be due to external factors (changes in the kind of functionality requested, crunch times, etc.) or internal factors (learning, change of personnel, change of practices, etc.).

Nerdy things I want to learn properly

2010-07-04T17:03:00.000-07:00

Git (fast, distributed version control):

Org-mode (TODO + tagging + calendar + outliner on steroids) in Emacs :

User manual
Carsten Dominik's Google tech talk
"Getting Things Done" with Org mode and Emacs
MobileOrg: Free org-mode on the iPhone

Resources for learning Javascript and jQuery

2010-06-19T14:21:00.000-07:00

Douglas Crockford's JavaScript articles and book (JS: The Good Parts)
John Resig's blog and JS Secrets book
Rebecca Murphy, jQuery Fundamentals (inludes JS primer)

Turning MS Office into a game

2010-06-15T19:12:00.000-07:00

There's now a plugin to Microsoft Office, Ribbon Hero, that adds simple game dynamics to encourage users to better learn how to drive the darn thing, betwixt coffee breaks.

Informative article, here. Excellent slides:

Beats the hell out of reading the manual.

Bad writing

2010-05-04T17:31:00.000-07:00

"The truth is, most US academic prose is appalling: pompous, abstruse, claustral, inflated, euphuistic, pleonastic, solecistic, sesquipedalian, Heliogabaline, occluded, obscure, jargon-ridden, empty: resplendently dead."

-- David Foster Wallace, in Authority and American Usage

Seen on Hacker news. See also this article on business writing.

C# is slowly turning into Eiffel

2010-04-13T18:48:00.000-07:00

When I first read Bertrand Meyer's fabulous tome, Object-oriented Software Development, (2nd edition). in 1997 I guessed that it was ten years ahead of its time. Seems like I wasn't too far off the mark, with .NET 4 introducing language independent support for Design by Contract, as code contracts, and patching up some of the covariance and contravariance issues of previous versions.

How long it will take for most programmers to use the techniques well is anyone's guess, but having mainstream tools that support these approaches is a good thing.

Non-functional requirements

2010-04-07T21:40:00.000-07:00

There's a lot of unglamorous stuff in software that is just "expected", and accounts for some of the project cost that you will miss when imagining two guys in a garage (or cafe) knocking out a quickie project. Here's a handy list: Non-functional requirements: Minimal checklist.

ToneMatrix: A fun, simple music synthesizer

2010-03-11T15:27:00.000-08:00

ToneMatrix (Flash-based): The pattern determines the sound. Example pattern:

Right-click copy and paste let's you save compositions as text.

Examples abound in the reddit discussion.

I must try my kids on this ...

Harmony: A neat drawing tool in JavaScript

2010-03-10T19:21:00.000-08:00

Flash-free graphics in the browser is getting easier to do, and snazzier:

Try it here. View the source to see the JavaScript.

mmmm ... CoffeeScript

2010-03-08T19:31:00.000-08:00

The most commonly used programming language in the world today, certainly within the browse, JavaScript superficially resembles the Java programming language in its syntax, but at deeper levels it owes far more to lesser-known languages, such as Scheme and Self.

The Java part of the name and syntax apparently came about as a result of a decree from Marketing that Java was the next hot thing, and inventor Brendan Eich worked feverishly to swiftly put a Java-esque sheen over the top. This, plus the cutesy name, helped mislead a lot of people for a lot years into thinking that it was a toy scripting language, and only with the more recent success of AJAX has its underlying power come to the fore.

And yet we are still burdened with the clunky syntax.

However, CoffeeScript promises to change that, with a new, lightweight syntax for JavaScript that owes a fair bit to Python and Ruby syntaxes, and a lot to experience with JavaScript. An example:

# Uses a binary search algorithm to locate a value in the specified array.

binary_search: (items, value) ->
 
  start: 0
  stop: items.length - 1
  pivot: Math.floor((start + stop) / 2)
 
  while items[pivot] isnt value and start < stop
 
    # Adjust the search area.
    stop: pivot - 1 if value < items[pivot]
    start: pivot + 1 if value > items[pivot]
 
    # Recalculate the pivot.
    pivot: Math.floor((stop + start) / 2)
 
  # Make sure we've found the correct value.
  if items[pivot] is value then pivot else -1
 
 
# Test the function.
puts(2 is binary_search([10, 20, 30, 40, 50], 30))
puts(4 is binary_search([-97, 35, 67, 88, 1200], 1200))
puts(0 is binary_search([0, 45, 70], 0))
puts(-1 is binary_search([0, 45, 70], 10))

At time of writing CoffeeScript is only up to version 0.5.5, and syntax is not guaranteed to stabilize until 1.0, but IMO it's well worth a look.

P.S. A neat little blog post about CoffeeScript (with short examples) from Thomas Reynolds.

P.P.S. There are similar tools/nicer syntaxes for HTML (HAML), and CSS (Sass).

What makes a good entrepeneurial blog

2010-03-02T15:59:00.000-08:00

In his good-bye to blogging article Joel Spolsky of Joel on Software fame paraphrases Kathy Sierra:

To really work, Sierra observed, an entrepreneur's blog has to be about something bigger than his or her company and his or her product. This sounds simple, but it isn't. It takes real discipline to not talk about yourself and your company. Blogging as a medium seems so personal, and often it is. But when you're using a blog to promote a business, that blog can't be about you, Sierra said. It has to be about your readers, who will, it's hoped, become your customers. It has to be about making them awesome.

Now, that's not the aim of this blog, which started off as a combo. semi-regular frustrated rant / the traditional idea of a web log (keeping a log of cool things the author found on the web) / cute things about my kids, but nonetheless I reckon it's spot-on.

They should be remaking bad movies ... and fixing them

2010-02-10T21:32:00.000-08:00

Wise talk from Ed Catmull, president of Pixar and Disney Animation studios, on what he's learned:

Gems (paraphrased):

Give a good idea to mediocre people and they'll muck it up; give a mediocre idea to good people and they'll fix the idea, or throw it out and get a good one.
A movie or product isn't just one idea, it's thousands, and most of them need to be done right for you to succeed, so you need a good team
People are always remaking good movies; they should be remaking bad ones that were based on good ideas, but poorly executed
People and how they function is more important than ideas
It's very possible to misunderstand the reasons for your success
What's important are the things that affect behavior

Plus insights into why people don't like to do post-mortems, gaming "the system", communication structure vs company structure, and why successful companies fail.

Hygiene and Motivation

2010-01-31T14:50:00.000-08:00

In Nine Things Developers Want, Rob references Herzberg's Two Factor Theory:

In the 1950s a researcher named Frederick Herzberg studied 200 engineers and accountants in the US. He asked them a few simple questions and came up with what is one of the most widely-accepted theories on job satisfaction called Two Factor Theory.
His theory breaks job satisfaction into two factors:
hygiene factors such as working conditions, quality of supervision, salary, safety, and company policies
motivation factors such as achievement, recognition, responsibility, the work itself, personal growth, and advancement
Hygiene factors are necessary to ensure employees don’t become dissatisfied, but they don’t contribute to higher levels of motivation. Motivation factors are what create motivation and job satisfaction by fulfilling a person’s need for meaning and personal growth.

In his cracking TED Talk Dan Pink delves into some of the behavioral research that explores the consequences of using extrinsic factors such as monetary rewards as motivational tools:

Bottom line: extrinsic rewards tend to narrow focus and hamper creativity.

Some powerful Javascript tools

2010-01-28T15:05:00.000-08:00

As the web-browser turns into the client of choice, it's good to have powerful tools to hand. To whit:

HTML/CSS manipulation (esp. for Ajax): jQuery
Javascript Optimizer/Checker: Google's Closure compiler
Information Visualization: JavaScript InfoVis Toolkit and Protovis
Javascript charts and graphs: A selection of 13 tools
Vector graphics: Raphael (plus charting extension, gRaphael): clock example
Client-side GraphViz: CanViz
Background processing: Web-workers
Push: Web-sockets

No doubt more to come.

See no evil, hear no evil, speak no evil

2010-01-21T01:25:00.000-08:00

The three wise monkeys together embody goodness of mind, speech, and action.

Daughter Ella, aged four, embodies cheekiness of mind, speech, and action.

My son just conducted the Melbourne Symphony Orchestra!

2009-11-20T22:23:00.000-08:00

This morning our family went to a Classic Kids concert given by the Melbourne Symphony Orchestra. Lots of fun music and dancing and learning about the instruments and sections of the orchestra. The different sections were dressed in different colored tops to aid identification, a la the Wiggles, and the conductor had a multi-colored top on.

The MSO, in more formal attire

A boy and girl were selected to conduct The Liberty Bell, and my kids, who were seated at the front were predictably disappointed not to be picked. But wait ...

After kicking off the finale, The William Tell Overture ("Hi ho Silver - away!"), one of the most thrilling showpieces in the orchestral repertoire, the conductor, Ben -- Benjamin Northey, bless him, may he have a long life and outstanding career -- dashed into the audience, asked Jake's Mum if he'd like to conduct (swift affirmative response), and led Jake to the podium where he handed Jake the baton. Jake proceeded to perform with verve, enthusiasm and undisguised joy for about 3 minutes, all the way to the end of the finale, followed by wild applause from the audience.

Benjamin Northey, my favorite conductor

It was awesome. I was in tears, Andi (Jake's mum was in tears), and Ella no doubt expects to get to conduct the orchestra next time round. It was awesome and inspiring. A child came up to Jake afterwards and said that he was better than the real conductor; that kid will not grow up to be a music critic, but bless him too!

On questioning Jake said that the fast bits were more challenging to conduct than the slow bits, and that even though conducting was fun, he would prefer to be an inventor of new musical instruments when he grows up than an orchestra conductor.

Jake played Moses at kindergarten (with stick), and conducted the MSO at age 5 in the William Tell Overture with baton. What a little legend!

Andi's post on the same incident.

Update: Andi wrote to Benjamin Northey to thank him. Here's his reply:

From: Benjamin Northey
Sent: Sunday, 22 November 2009 11:32 AM
To: Andi Herman
Subject: Re: Thank you

Hi Andi,

So kind of you to share this with me. Jake was pretty much the highlight of the week for us! The orchestra loved him and as you say, to see such pure joy was very special indeed - very moving. Loved reading the blogs also.

I hope that this is something Jake will remember for a long time. Please say hi to BOTH of your children from me!

all best, Ben

We hope so too. Thanks again, Ben.

So he writes books about movies?

2009-11-17T12:38:00.000-08:00

From the "Overheard" section in mX:

Girl: I'm going to see Taming of the Shrew.
Friend: Is that like the book that's based on the movie Ten Things I Hate About You?
Girl: Not quite. It's by William Shakespeare.
Friend: Didn't he do Romeo and Juliet?
Girl: That's the one.
Friend: So he writes books about movies?
Girl: Have you ever been to English class?

Classic.

Opposite rhymes

2009-11-13T03:09:00.000-08:00

My daughter Ella, who is not yet four, has invented a new word game called "opposite rhymes".

You know how the word game "opposite pairs" works: Name pairs of words that are opposites. For example:

Big - little
Black - white
Hot - cold

And "rhyming pairs":

Fiddle - middle
Hot - cot
Head - said

But in opposite rhymes (also known as rhyming opposites) you have to do both at once, making it considerably harder:

Ella: Tall - small
Andi: Happy - crappy
Andi: Sad - glad
Dan: Familiar - unfamiliar (deemed unacceptable)

So I'm pretty impressed with my little girl for inventing this new form of wordplay and finding the first one.

Can you find of any others? It ain't easy.

Which religion should I follow?

2009-11-08T15:47:00.000-08:00

Gone are the days when one simply followed the religion of one's forefathers and foremothers. For those who find themselves confused by all the different choices on the market, here's a handy visual guide:

Click for a larger and clearer version

Hopefully people of all faiths and non-faiths are equally offended and amused.

Promoted - again!

2009-10-26T15:41:00.000-07:00

It seems to be the season. Around this time last year I was promoted to CTO, and this time round, my boss has decided to move on, and I have stepped up to the hot seat of CEO-dom.

All of this has been bad for my Kibitz blogging, although I have been contributing to a new blog all about our emerging visual collaboration product: bCisive Online:

A diagram quickly knocked up in bCisive Online - click to enlarge

Divide and conquer meets visual thinking meets true real-time collaboration. Interested? Check it out, and get in touch.

That said, I'll try and post the occasional kibitz or update here too.

bSelling from the Top Down (and bottom up)

2009-05-14T16:49:00.000-07:00

When we first developed bSelling Opportunity Management Software we had a choice: Focus on bottom-up or top-down issues.

We chose bottom-up first: Make the software easy and fun to use, and useful to the individual sales rep.

Almost immediately, our early adopters made us very aware that as much as they loved what we already had, there were burning top-down issues that needed to be addressed asap:

How can the sales manager get an effective overview of all open opportunities? And then drill down.
Similarly, how can an individual salesperson get perspective of all his opportunities in order to better gauge where and how to focus effort?
How can a sales manager customize the qualification process to fit her team's needs?
How can a sales person or manager share insights with other team members, or present a pitch to clients?

We listened and have carefully crafted some exciting new features, again blending visual flair with smart functionality:

Better overviews: The bSelling Opportunity Explorer

The bSelling Opportunity Explorer is a new dashboard that shows every open Opportunity and positions it graphically based on its qualification percentage -- the likelihood of success as determined through the bSelling flip-card based Qualify tool -- and the expected Amount in $ from a successful close:

Click to view a larger image

The size of the bubble shows how much effort the rep. has been devoting to the opportunity. Hovering on an opportunity identifies it and gives precise numbers. Clicking opens up bSelling for that opportunity.

Overview

Looking at the overall distribution gives an at-a-glance overview of where all opportunities are at, and where the effort is going. The four quadrants are labelled to assist interpretation:

Excellent: The upper right contains the best-qualified, highest amount opportunities
Safe bets: The lower right are well qualified, lower amount opps
Pie in the sky: The upper left contain the high amount, not yet well qualified opps
Poor: The lower left contains poorly qualified, low yield opps

Reading the patterns

With very little practice, certain patterns should start to leap out as meaningful:

In the image above the line of small circles on the vertical axis are unqualified opportunities. Why haven't they been qualified yet?
Large circles in the left quadrants reflect opportunities where a lot of effort is going in without much progress. Some of the "pies in the sky" may be worth persisting with (for a while), but the "poor" opps need to be quickly qualified across or dropped.

For the individual salesperson this overview can be a powerful tool to help manage his pipeline. For the manager, it allows her to see how the team as a whole is performing, and focus action where needed.

Customization: Tailoring the process

The bSelling Qualify Tool adds rigor and guidance to qualification by asking the salesperson to flip through virtual card-decks that rate all the important factors associated with an opportunity.

It is now possible with bSelling premium to customize this standardized tool across a team or organization to meet a preferred methodology or to cater to specialized needs:

And here's an in-depth overview.

Sharing: Exporting to PowerPoint

Sales and account managers often need to report on key opportunities to executives and other non-sales colleagues. To illustrate their understanding of an opportunity and to help their audience understand the client contacts' perspectives, bSelling premium now includes a convenient "export to PowerPoint" facility in the Diagnose Pain tool.

When pitching to a customer, diagrams prepared in Present & Sell can be turned into a sequence of PowerPoint slides in the same way.

Conclusion

bSelling remains fun and friendly, but has grown more power-packed.

It blends bottom-up advantages (usefulness, simplicity, fun) with top-down virtues (overview, customizability) and communication (visualization, PowerPoint export).

We'll keep refining it, and can also further customize to meet more specialized needs.

Fartlek development

2009-04-16T16:18:00.000-07:00

The amusingly named Fartlek training is a form of athletic training in which high intensity work and low intensity work are alternated in the course of each training session. The two forms of work are complimentary in that they stress the you in different ways (anaerobic and aerobically) and allow you a chance to recover.

I think that this is a good model for software development in software start-ups.

Priority one: Build something that people want, fast

The main risk in a software start-up is making something that people don't want. So you want to find out whether your initial idea has merit, fast. So -- if at all possible -- you build a small prototype, and test it out in the marketplace, fast.

In order to satisfy the need for speed, you cut a few corners, and because it's small (and your team is good) you can get away with this approach (for now).

If no-one wants your prototype, you scrap it, and you haven't wasted time on lots of process that was supposed to pay off in the long-run (because there is no long-run).

On the other hand, if it the prototype is promising, you will learn from the market feedback how to make it better, and it will start to grow. This is where it is critical to switch gears and slow down (at least for a while). Because if you do not, you will find yourself in the realm of cowboy development, the bugs will start to bite, and the pace of development will drop as your team gradually spends more and more time debugging, less time developing, resulting in a drop of confidence -- "I don't want to quickly make this change because it might break something" -- and loss of tempo.

Priority two: Restore quality (and sanity)

The alternative is to switch modes. Fred Brooks said "build one to throw away", but at a minimum you should review what has been done to date and investigate and prioritize the very real risks of continuing with a prototype. These might well include:

Customer or prospective customer loses data or has it corrupted
Customer or prospective customer experiences bugs, crashes, or loss of service
A crash or a bug during a demo
The software does not scale, so performance degrades over time
Development slows so that critical new features can not be delivered in a timely fashion

Improving the quality of the software process is what is needed for most of these, and many of the kinds of measures that help have largely been formalized in the Agile development processes:

Pair programming: Two heads are better than one, plus it offers real time code reviews, mentoring, camaraderie and friendly competition, less web-surfing
Test-driven development: Writing automated tests clarifies the design and as they build up offer an early warning system when a change breaks something unexpectedly (Design by Contract gives similar benefits)
Continuous integration: Frequently "checking-in" and automatically running the automated test-suite identifies incompatible changes made by different programmers or pairs sooner rather than later; saves you from merge hell
Refactoring: By reviewing code, eliminating duplication, reducing coupling, and improving the use of abstraction, your software base will become more concise, readable and maintainable
Short iterations / planning game: By maintaining a list of feature requests and bug-fixes that the developers estimate and the internal customer prioritizes (within a budget based on the amount of work accomplished in the previous iteration), a sustainable rhythm is established, and healthy prioritization is forced
Sustainable pace: Working more than an eight hour day / forty-hour week leads rapidly to damaging the code base, loss of morale, and bull sessions as people are present in body, but not in spirit -- avoid the "Death march" scenario

Additionally, a design review will be needed to knock the existing architecture and code into shape, and tests will needed to be added retrospectively if you didn't practice test-driven development in the initial prototype phase.

For a web-based service additional infrastructural elements and diagnostics should be reviewed and added.

All of this is manageable as long as the prototype is small, but the longer these steps are delayed, the greater the costs that must be paid. It's a lot like going into debt. You not only have to repay the loan, but also the accumulated interest. Some people call this design debt. (And the interest rates on design debt tend to be high.)

And then the cycle turns

While making incremental changes continued agile iterations is probably the way to go, slow and steady (but not slowing down). When the time comes to make a leap forward, knocking up a quick prototype is a great way to vary the routine, and makes business sense.

Conclusion
Almost everyone who learns to program first experiences the joys of "cowboy development" on small personal projects, but when they "turn pro" or start working on larger projects they soon learn that it doesn't scale beyond what you can easily hold in your head.

Some people think that up-front design and analysis will save the day, but this leads to waterfall with its 1/3 design, 1/3 development, 1/3 testing rule-of-thumb when done well. But then you discover that the requirements were wrong (they always are), and another long iteration is required.

Smart people rediscover short iterations, and lately these have been articulated as Agile Methods, and also include other ways to make the computer (e.g. automated tests) and human nature (e.g. pair programming) work effectively and more satisfactorily. The cost is a bit of deferred gratification by having to do some things up front (e.g. writing tests, refactoring) that pay off over time.

However, it would be wrong to say that an Agile approach is the best for everything, at every scale. In particular, in knocking up a quick prototype one may well be justified in reverting to some of the cowboy practices for a short period. Note that it is not compulsory to drop all the agile practices when doing so -- do what suits the situation.

The tricky bits are:

Not leaving it too long
Paying off the accumulated technical debt
Getting back into the discipline of following the practices
Combating the likely organizational pressure to continue at the previous pace!

So good luck with the fartlek development*, and let me know what you think.

*My esteemed colleague -- and former Olympian -- Ben Loft points out that interval training may offer a better analogy, but the name isn't as memorable.

Provocation-based Selling (and Provocative Writing)

2009-04-12T18:57:00.000-07:00

Who doesn't love a controversy? Want to get noticed? Provoke! Capture attention!

The trick is to follow up with something that hits the spot lest you alienate your suddenly alert audience.

One way to provoke attention is to insult a big-name. In a recent article in the Harvard Business Review -- In a Downturn, Provoke Your Customers -- the authors (including Geoffrey "Crossing the Chasm" Moore) slam the generic notions of consultative selling and especially solution selling (as opposed to the more specific Consultative Selling and Solution Selling®) either through ignorance or in a straightforward grab for attention.

The only problem -- as Keith Eades, CEO of SPI correctly points out -- is that they have done so to a large extent by over-simplifying Solution Selling, and then comparing their "new" approach to a whittled down husk:

Whereas solution-selling salespeople listen for “pain points” that the customer can clearly articulate, provocation works best when it outlines a problem that the customer is experiencing but has not yet put a name to. -- from the article

But Solutions Selling has a powerful way to think about where your customer is at, before getting into "pain points": Levels of Need*:

Latent need: Unaware of a need that could be satisfied by purchase (perhaps they are unaware that there's a problem, or in denial, or resigned to coping with the status quo)
In pain: Aware of the need ("in pain"), but unaware of how your offering can help
Vision creation: The prospect has a vision or a "Solution", ideally including your offering.

A key part of Solutions Selling is to move the customer upward through these Levels of Need. The article mis-characterizes Solution Selling as simply asking the prospect about their pain (i.e. jumping in at level 2 - In pain), while correctly pointing out that during a downturn many more people will tend to be at level 1 because they are doing their best to make-do with much-reduced budgets and discretionary funds.

A key part of "provocation-based selling" seems to be to provoke a response by forcefully articulating a problem that the customer has, get them to acknowledge it, and then make a bee-line to the person who has the authority to do something about it (and who can release funds to purchase).

This is all good Solution Selling, just in slightly different terms. In classic Solution Selling one would first try to stimulate the interest of a contact with a Reference Story, typically describing a person in a similar situation to their current one and how you were able to help that person. Hopefully the contact will respond by either confirming that (s)he has similar issues, or -- equally good -- say something like, "No, we don't have those problems. This is what's really bugging me ...". Either way, you are engaging and on your way to level 2. While exploring the prospect's pain, you should also be finding out who else is affected (i.e. who else you need to speak to get a fuller organizational picture of the pains, and also who can authorize a sale), etc. [I have a fuller summary of Solution Selling here.]

The authors of the HBR article have a good point to make: That during a downturn a forceful -- or provocative -- approach may be a good way to jolt prospects into thinking about what can be done to improve their business, including alerting them to problems that they may be reluctant to address. They suggest a mixture of fear -- "if you don't do something you're doomed" -- and hope -- "but we can help you get through this". This seems like a good approach, provided you have accurate information, and can pull it off without alienating your prospect by coming across as arrogant: "I know your problems better than you"!

So "props" to the authors of In a Downturn, ... for being provocative, and thereby garnering some attention for the important issue of jolting people out of latency during a downturn.

My guess is that the authors feigned ignorance of Solution Selling etc. to whip up controversy, and that's probably a good thing!

* Austhink's add-on to SalesForce crm -- bSelling Opportunity Management -- augments SalesForce's contact information (which is a bit more Miller-Heiman-esque out-of-the-box) with a Level of Need field. Naturally, we also do pain points!

To Customize is Cool

2009-04-07T18:20:00.000-07:00

It's cool to customize! It practically has the word "customer" in it, so what's not to love?

Seriously: When prospective customers see the Qualify tool -- part of Austhink's bSelling add-on to Salesforce crm ...

they say two things:

Wow!
Can I customize it?

The "Wow!" reaction is because here is a tool that really helps the salesperson with a vital but difficult task -- sales qualification -- in a fun way. It provides useful feedback -- an overall percentage, and sensible concrete ways to boost the score. Ok: Most of the wow is because of the fun factor and groovy way it plays (like flipping through photos on a Mac).

The second reaction -- the wish for customization -- is natural. Although at Austhink we believe that the out-of-the-box system is quite generic, sales teams do of course vary in their terminology, types of customers, and overall slant sales.

So, I recommend a suck it before you salt it approach:

Try out the generic version (that comes with the free version of bSelling) on a few opportunities to get the feel for the process. Just pick a neutral "card" if a factor doesn't seem to apply.
Make notes about where the terminology needs revision, which "factors" don't apply, and which (if any) are missing.
Upgrade to the premium version of bSelling and make use of our soon-to-be-released customize feature.
If you need extra help, we can arrange consultation!

The customize feature allows your company to change the wording, options, factors, and weightings -- i.e. everything -- of the Qualify tool to tailor it to fit your unique situation. Just like the tool itself, it looks great, is fun-to-use and it has a game-like feel. Here's a sneak peak:

Each line represents a deck of cards in the tool, and each block represents a single card. The length of each line represents the weight of each factor. You just click on a box to edit some wording (shown), or click on an end box to stretch or squash a line (to make a factor more or less important compared to the others). Other operations are similarly simple.

By the way: If you think of the Qualify tool as a level in a game, the customization tool is like the level-designer that allows an obsessed user to design new game levels for their friends to play. In this case, the customization tool allows the sales-manager to tweak (or totally revamp) the qualification process to fit local conditions, and better monitor (and mentor) the sales team.

We are about to trial the customization tool with a select group of beta-testers -- email me at dan@austhink.com if you want to give it a whirl -- and the first version should be available in the next week or so.

From Moses to Moses ...

2009-04-03T22:08:00.000-07:00

"From Moses to Moses there was none like Moses". The two Moses's of the quote are Moses the lawgiver -- he 0f the 10 commandments etc. -- and Moses Maimonedes the greatest Jewish sage of the middle ages.

Loyal readers of this blog will remember that last year my son Jake portrayed the earlier Moses in the kindergarten Pesach (Passover) play:

Jake as Moses

Witnesses said that his manner and physical resemblance to the biblical Moses was uncanny, and it seemed it would be a long time before anyone would else would pull off such a convincing portrayal ...

That was until Jake's little sister Ella put on the beard!

Ella as Moses

Apparently Ella was a little more tentative in her portrayal than Jake had been, but she is a year younger than he was when he took on the role.

Nevertheless, I am again very proud indeed. (And amused.)

First web-based product released: bSelling

2009-03-15T14:10:00.000-07:00

Last week we -- Austhink Software -- released our first web-based product, bSelling Opportunity Management, an add-on application to the web-based Salesforce CRM.

Yay team!

Here are some brief notes about the product (a visual tool to enhance the performance of sales teams), its placement (as an add-on to Salesforce CRM available through salesforce.com's AppExchange), and the development experience (using Adobe Flex + Django talking to Salesforce).

The Product
The best way to get a taste for this add-on, which helps the salesperson to better Qualify (i.e. estimate the percentage chance of closing the deal) , better understand the customer's pain(s), and ultimately pitch more effectively to the customer's needs -- is to check out the 2 minute (approx.) introductory video:

bSelling video

For non-sales people, here's my distillation of Solution Selling, one of a family of consultative approaches to sales -- along with SPIN, Strategic and Consultative Selling -- that bSelling is intended to support.

The Placement
Austhink's Softwares previous products, bCisive and Rationale were PC-based and intended to create new markets: Rationale for improving Critical Thinking in education, and bCisive for applying Visual Thinking to business.

For our first web-offering we decided to pick a more targeted application -- consultative selling -- and apply our visual approach more narrowly. This enabled us to go from "let's port bCisive to the web" (a daunting undertaking on account of the size of the pre-existing product) to "let's port the bits of bCisive that will help with consultative selling" (a smaller and more customer-centric) undertaking.

We aimed from the outset to put the resulting application on Salesforce.com's AppExchange, as a way to make bSelling visible to our chosen market segment, and to offer easy integration with the leading web-based CRM.

Development Experience
We accomplished this with a team of 3 in just over two months, admittedly making use of some initial work on a web-port from last year, plus our accumulated experience from bCisive, Rationale and some earlier non-commercial web-based projects, most notably Aaron's side-project, Path of a Hero.

We found that Adobe Flex / AS3 gave us the graphic power (and portability across browsers) that we wanted for the front-end, with our architecture hanging off a slightly souped-up version of the PureMVC framework. We use Django / Python / MySQL for the back-end and use AMF3 / PyAMF to get fast communication between the back and front-ends.

The big unknown for us was integration with Salesforce CRM. It turns out that their APIs and docs are pretty good, and we were able to embed our app as a web-page in their S-Control.

Now, it is possible to build apps entirely on their force.com platform, but we chose not to because:

It required a steeper learning curve
We had a pre-existing technology investment
It would couple us completely to their platform

On the negative side this meant that we had to subject ourselves to a nerve-wracking security review. This involved submitting our organization's written policies plus go under attack from their review team. It was certainly "an experience", a bit liking going back to University for another exam, but their liaison was helpful in guiding us through the process, and we achieved a provisional pass first time (much relief).

One note for start-ups: There is normally a $US5000 application fee for the review (annual!). The two ways to waive this are to develop directly on the force.com platform (i.e. inside the Salesforce sandbox), or to supply a free version of your app. We went with the free version.

Compared to the security review, the final review was less demanding.

The Future
We are putting the finishing touches on an "export to PowerPoint" feature for the paid version, so that a salesperson can grab some snappy visual slides to supplement customer presentations.

Naturally getting the word out is paramount -- thanks to AppExchange we've already had some people checking out the video and installing bSelling-- and we look forward to responding to customer feedback with further refinements. To this end we have set-up UserVoice to help out with this. The AppExchange infrastructure requires people to leave details, so we will also follow up (selectively and politely) with some of the early adopters to find out worked and what didn't.

Beyond bSelling on Salesforce we are also look at integrating it with other online platforms (SugarCRM is an obvious candidate).

And beyond that lie other applications in Sales and other business verticals. We aim to apply our skills and technology to create other "Enterprise 2.0" apps, but in these -- ahem -- challenging times we need to be strategic about picking off targets.

Hooray for Captain Balding! And Captain Underpants!

2009-03-13T15:54:00.000-07:00

Having recently started school, my son Jake reports that he spends many a happy recess playing super-heroes with his friend, Max:

Which super-heroes do you play?

"I am always Captain Balding and Max is always Captain Underpants.", says Jake.

Intriguing. What is Captain Balding's super-power?

"We have different powers every time, but one power we always have is super-phones."

It all sounds marvelously imaginative, and they are fixated on these characters. But where do they come from? My best guess is that the Captain Balding character originated as a kind of a cross between me -- bald and apt to make my children address me as "Captain Daddy" -- and Groucho Marx's Captain Spaulding in Animal Crackers:

Song: Hooray for Captain Spaulding (not Balding)

Now, as for Captain Balding's great partner in crime-fighting, Captain Underpants, a little research reveals that he is a legit. super-hero after all:

Captain Underpants rap

With these two heroes to protect us, we simple townsfolk can again sleep safe at night ...

... I think.

This Prager is a bigger nerd than me

2009-03-11T21:31:00.000-07:00

We share the same initials and the same surname, but David Prager is (clearly) a bigger nerd:

When a stranger broke into Silicon Valley executive David Prager's house yesterday, he did not call police or reach for a gun - he logged on to Twitter and set up a live video stream.

Read on ...

So there you go: Another D. Prager -- other than Dennis -- in the news.

Three things that my children have learned

2009-02-20T17:21:00.001-08:00

Just for fun I asked my son, who has just started school, what three things he has learned at school. Jake's (very definite) response:

Respect,
Sport, "and finally:"
Italian.

I then asked a similar question of my daughter, who has recently commenced kindergarten. Ella's reply:

How to draw,
That [another child] is not my friend, and
That I do not know how to draw.

HtDP for the experienced programmer

2009-02-18T14:05:00.000-08:00

I am a fan of Scheme (a programming language for the soul) and SICP "the greatest book on programming ever written", but my hat goes off to the creators of DrScheme, a great interactive environment for the beginner and experienced programmer alike.

The other night I swallowed my pride and started to work through HtDP (How to Design Programs), the PLT Scheme gang's reaction to the fact that SICP (which came from MIT) while great for the suitably talented individual does not by-and-large work for the mainstream. In this book they explicitly teach program design, a systematic approach to thinking and problem-solving that it seems only a few people get by the more traditional osmotic process.

HtDP is covers a great range. Although principally geared to college level, it can be taught in high schools (at a slower pace), and can teach most experienced practitioners more than a thing or two.

Additionally, the people on the PLT Scheme mailing list are incredibly friendly and supportive. Here's what Matthias Felleisen, first author of HtDP (among many other things) wrote when I mentioned that I was starting to work through HtDP, but was having difficulty restraining myself from skipping ahead:

If you are an experienced programmer, you should read HtDP like this:
Read the sections whose title starts with "Designing ...."
Also read the "iterative refinement" sections
Pick five exercises in the preceding and/or follow-up section and solve them according to the recipe
[my emphasis]
Unless you're stuck move forward
Try to understand the "symmetry" between data definitions and templates
I expect that somewhere around late part II, you will slow down. You may pick up real reading as of part III, though some may make it thru III and only "stutter" in IV.

Also:
Use check-expect to express your examples/tests
Avoid draw.ss exercises, replace them with world.ss but that's a non-trivial switch
And holler if you are having trouble -- Matthias

In short: Great tools, great teaching materials, supportive and experienced community.

Software Product Design and the Collaboration Process

2009-02-18T13:37:00.001-08:00

In the last few months my team and I at Austhink software have had a wonderful graphic designer -- David Urbinder -- consult on our products. Much more than design icons and images, collaborating with David has led to improvements in overall visual design, and more deeply into dynamic behavior (interaction design) and consequently the overall usability and appeal of our products.

Working with someone from a complementary design background helps to trigger creative sparks. David has pointed me to this article by Nate Fortin about the non-separability of design into different disciplines in Cooper Journal. Cooper Journal is hosted by Cooper Design, whose principal Alan "Father of Visual Basic" Cooper wrote the influential book About Face, and the provocative and important The Inmates are Running the Asylum, both of which I also highly recommend.

One of the issues that we are grappling with is how best to engage expert outside design consultants like David. At the moment we are doing a blend of some consulting time, plus directed tasks, spread out over time. The benefit of the spreading out is that we get the benefit of David's creative input early, when it can have a formative effect, and guidance at later stages too as the product becomes more "locked down". Coordinating our schedules is a "fun" part of this approach, and is of course more challenging than just employing him for confined blocks.

Finally, if you want to commission David, I would love to link to his web-site, but I believe that it is not ready for public consumption just yet (hint, hint ;-). In the meantime, David can be contacted on email at urbinder@gmail.com.

New tag line?

2009-02-16T15:14:00.000-08:00

The problem (from my last post): Get our draft mission statement:

We use our skills in software, game design and visual animation to make our customers' business applications more fun (and much more effective).

down to a snappy under-five-words tag-line.

Here is an unfiltered list that I came up with while sitting through a talk on "cloud computing":

Make work fun
Make work visual and fun
Make work fun and visual
Work as a game
Game the system
Games that work
Turn on your brain
Work meets play
Smart play
Intelligent play
Play smart; work smarter
bFun. bSmart.

More ideas?

Mullenweg's 12 rules for getting from 1 to 100,000 users

2009-02-15T15:12:00.000-08:00

Matt "Wordpress, Akismet, Ping-o-matic" Mullenweg has 12 rules for getting to a large number of users:

You have to be the most passionate person involved.
Get off the computer - the act of writing things down on paper frees the mind, allows for the juices to really flow.
Obsess about the details, down to the space between two letters.
Do your own support. You have to be able to feel the pain of your users. Document everything. Make it as easy as possible for your users to contact you.
Blog every step of the way. Keep all of your users in the loop at all times - they will love you. Communicate with them and put them in the driver's seat.
Have a great tagline. If you can't describe what you are doing in less than 5 words, edit it, shave it down.
Frame everything you're talking about in a context for your users. What are you going to do for them?
Get out of version 1.0 as fast as possible. Most people make their successes on something different from where they started. Be flexible. User feedback is the most valuable asset. Don't let yourself be too led by your first users. Listen to the silent majority. Keep the majority in mind.
Track yourself.
Know what to do if you are successful.
Start strong, end strong. People don't often remember what was in the middle.
Be a pain killer, not a vitamin.

The 46-minute podcast of Matt's talk.

Excellent food for thought. One that caught my eye was #6. The problem: Get the shiny draft mission statement down to a snappy under-five-words tag-line.

Victorian bushfires: A personal appeal

2009-02-10T18:18:00.000-08:00

Unprecedented bushfires have affected my home state of Victoria, Australia, since last Saturday. I live in the capital city, Melbourne which has been largely unaffected, but like almost everyone else I have friends and family who have had narrow escapes.

Unfortunately, many have not been so lucky. Over one-hundred-and-eighty people are confirmed dead with estimates that this will rise to over 300.

Today I was saddened and shaken by the news that a family that I know -- a mum, a dad and two children (only a few years older then my own) -- perished while defending their home.

What to do?
Like most Victorians we are donating money, in our case through the Red Cross Bushfire Appeal. In addition Andi is donating patchwork quilts to the destitute. We are looking into other ways that we can help.

I urge all Australians -- especially Victorians -- to donate generously, and if possible to also help by donating goods, personally volunteering, and offering shelter to those rendered homeless.

My son the vigilante

2009-02-09T13:23:00.000-08:00

In the round-up to Jake's first week at school, when asked about his day, Jake said in passing:

"I had to wrestle one boy, to stop him from being mean to another child."

Further questioning failed to yield meaningful elaboration. In the absence of calls from the school I guess we'll just have to assume (hope?) that Jake was on the side of the angels.

Shall we learn, or wrassle?

So to any bullies reading this, remember: "Don't mess with red".

Great interview question

2009-01-28T13:38:00.000-08:00

This article suggests that you should always ask

"What do you do in your spare time?"

since it tells you a lot about what the candidate is passionate about.

Now, I have been asking this sort of question in social settings because I am not a great smalltalker -- although I'd like to learn one day ;-) -- and usually asking that question (or what's your passion or hobby) get's people engaged and open up. Unfortunately some people are very obsessional and will launch into long monologues at the sniff of such an invitation, in which case it's time for me to interrupt, excuse myself and go and get another drink (especially in this heat).

Anyway, while I think it's an interesting question, I am not sure that it is that easy to interpret the answers. I would suggest supplementing it with a follow-up when there is no obvious connection:

"What have you learned from full contact macrame [or whatever] that relates to your day-job?"

Let the interviewee do the hard work!

Truth in Parody

2009-01-28T13:19:00.000-08:00

If you can't decide whether something is a conspiracy or a stuff-up, assume a stuff-up.

But often the conspiracy theory is much funnier, and just rings truer. Witness this spoof interview with Bjarne Stroustrup, creator of the C++ programming language. Snippet :

Bjarne: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers?

Gold.

Distillation of Solution Selling

2009-01-20T16:46:00.000-08:00

A few months ago we did a training course on Solution Selling, and yesterday I bought the book. After reading the introduction -- a bit more to go! -- thought that it would be a useful exercise to try to describe its essence in my own words:

Origins
Solutions Selling is a codification of smart sales practices by Mike Bosworth dating back to 1983. Originally Bosworth went straight from College to pursue a career in the technical support at Xerox corp., before it was suggested that he try his hand at sales, which he did (at first reluctantly). The book was published in 1995.

A Consultative Approach
Rather than foist your product on an unwilling (or even willing) prospect the Solutions Selling approach encourages you take the buyer's perspective and work with him or her in a non-pitchy way. By the end of the process a decision to buy should be a "no-brainer":

the customer should feel ownership of the resulting solution
the value should be evident to the customer how the purchase leads to enhanced capabilities
these enhancements should be quantifiable, so that the purchase price is justified to other people in the customer's organization
the customer should feel personally empowered by the experience and the result
the personal relationship with the salesperson should be perceived as positive

Applicability
Solution selling lends itself particularly well to large complex offerings. For example

Service and product combination
When you compete on customization and/or integration

However, the principles can be applied on smaller scales as well, exercising judgment about how much and which parts of the process to apply.

Theory
Let's divide prospective customers into groups / stages:

Not in target market: No need for your offering(s).
Latent need: Not aware of a need that could be satisfied by purchase
In pain: Aware of the need ("in pain"), but unaware of how your offering can help
Vision creation: The prospect has a vision or a "Solution", ideally including your offering

The key is to be aware of where the prospect is between steps two-to-four, and not get out-of-synch. with the prospect. Classic example: There's no point trying to tell someone that they need your product if they don't perceive it that way.

Examples:

If the prospect is in group 1, go after someone else rather than try to sell them something they simply don't need. Better to steer them in the right direction and build trust and respect for the longer term.
If the prospect is in group two, use appropriate questioning to get more clarity, but also to move the prospect toward a clear perception that they have a real need (which would move them into group 3)
Quantify the pain, find out who else in the client organization is affected (and go talk to them), find out who has the power to buy, find out which hypothetical capabilities would enable them to address their pain
Two possibilities: They are already heavily leaning towards a competing vendor's vision / offering (you need to realize this, and use FUD to un-sell them and get them to come over to your vision -- "re-engineering"), or use what was learned previously to put forward a jointly-developed vision that they know will give them real, quantifiable value.

Application
The actual Solutions Selling methodology explicitly fleshes out how to do it!

It includes lots of advice and tools including a detailed and distinctive nine-block vision processing model.

Challenges in putting it into practice
Naturally, Solutions Selling is not a panacea (silver-bullet):

In a freely available McKinsey & Co. report (registration required), Solutions Selling: Is the pain worth the gain?, the following points are made:

Unfortunately, our discussions with over 60 solutions sellers suggest that three out of four companies selling solutions fail to see sustainable economic impact.

They suggest that some possible keys to getting Solutions Selling to work well (my emphasis):

First, you have to understand how a solution is positioned in terms of two key variables, customization and integration. This positioning drives the basis of your competitive advantage and - most crucially -the "pain/gain" trade-offs you need to understand.

Then, you have to execute quite differently from a standard product-based go-to-market model in at least the first two - and preferably all - of five key dimensions:
Create distinctive solutions value propositions using customer business metrics, not product price/performance metrics.
Radically change the selling approach, and if necessary, the sales talent.
Price solutions based on total business value delivered, not component features.
Align the entire organization, not just sales, with the solutions opportunity.
Maintain control of all aspects of implementation to ensure end-to-end value delivery.
Solutions selling is not for everyone. But for those who understand and can implement these imperatives, there is tremendous upside.

Comment: The essential dimensions, one and two, on my reading amount simply to properly applying certain parts of Solutions Selling properly (as distinct, I suppose, from paying lip-service).

However, this may not always be simple. The report suggests that on average 2/3 of salespeople with a background in product-centered sales are unable to successfully make the shift to Solutions Selling. They recommend that "stars" be recruited from other areas, suggesting that star-sellers are either:

Already doing things similar to Solutions Selling (so the shift is smaller),
Are more adaptable than regular salespeople in terms of trying a different approach, or
Will be successful independent of the methodological approach adopted by the sales-team!

Conclusion
Solutions Selling is a consultative sales methodology that reminds me a bit of the Getting to Yes school of negotiation in that it aims to move away from negative relations between the two parties (e.g. adversarial, distrust, fear) towards cooperative problem-solving to seek out win-wins.

It has repercussions for the individual salesperson in that it encourages a specific systematic approach, but promises improvements in:

efficiently deciding which opportunities to pursue
improved client engagement
better professional relationships and reputation

leading to conversion-rate, sales figures and referrals. For the organizations that successfully embrace it, better sales performance is anticipated, but the following are needed:

Suitable organizational alignment with suitable offerings and pricing
Sales and other staff to execute on the approach (or at least most of it)

Granted organizational alignment, it stands to reason that certain organizational initiatives can increase the likelihood of individual and company-wide success when adopting Solutions Selling (and similar approaches):

Training
Mentoring
Recruiting
Technological support (tools that make the tasks easier, help apply essential parts of the methodology appropriately)

Inspiration

2009-01-20T16:01:00.000-08:00

Bob Franklin, who programmed up the first electronic spreadsheet, VisiCalc, in 1978 working with Dan Bricklin -- whose idea it was -- has been writing up the history. I found the following inspirational and salutory. How to build a software product:

Design Principles

VisiCalc was a product, not a program. Decisions were made with the product in mind and, to the extent possible the programming was towards this end. In practice it was more complicated as we were designing against the limitations of the personal computers, price point and, most important, what the user could understand.

The goal was to give the user a conceptual model which was unsurprising -- it was called the principle of least surprise. We were illusionists synthesizing an experience. Our model was the spreadsheet -- a simple paper grid that would be laid out on a table. The paper grid provided an organizing metaphor for a working with series of numbers. While the spreadsheet is organized we also had the back-of-envelope model which treated any surface as a scratch pad for working out ideas. Since we were used to working with powerful computers without worry about the clock running, we already had the experience of focusing on the users needs rather than the computers needs.

The ability for Dan and I to work as a team was crucial. While he could've written the program, the fact that he wasn't gave him the freedom to focus on what the program should do rather than how to do it. I could appreciate his reasons and would eventually accept that I had to change code that I had labored over. We were able to find ways to take advantage of the limited space available for the program in deciding what features to include or not include.

The original version put the entry area at the bottom of the screen. By playing with this simple prototype Dan found that it was better to put the entry area at the top of the screen and I made the change to the evolving program.

In addition to prototyping, Dan put together a reference card for users. If we couldn't figure out how to explain a feature on the reference card we would change the program. The original method for copying formulas was too complicated so we just changed the design rather than try to explain it.

The more things change, the more they stay the same.

Understanding the Financial Crisis

2009-01-14T15:25:00.000-08:00

Here's a readable explanation of the Financial Crisis as explained by a former president of the MIT Black-jack team, in terms of martingale strategies, reward systems, and self-deception.

Kids Rule

2009-01-14T09:25:00.000-08:00

Over the holidays we gave Ella her own room (formerly the "play room"), and redecorated both her and Jake's rooms in the process. They didn't really want to be separated, but were appeased when it was pointed out that they could visit each other for sleep-overs.

I felt that they should be able to set the rules in their respective rooms:

Jake's Rules for his Room

Don't take away a train when someone's playing with it.
Don't rip the Thomas and Mr Men and Little Miss books.
Don't break up the track.
Don't interrupt a story.
Be gentle with the lego.
Don't rust the trains, and don't scratch people.
Don't jump on the bed.
Be careful when you wind up the sling bridge; it might break.
Don't come in when I have privacy.
I like tickling, and stop when I want you to stop.

Ella's Rules for her Room

Don't jump on the bed, pillow and doona.
Don't interrupt my books and don't break my boxes.
I like tickling, but stop when I have had enough.

Andi and I are still working on our rules for the rest of the house, but here's a preliminary list:

Mummy and Daddy are the bosses of the house.
No biting, slapping, or hitting.
When you finish your food, bring your plate to the kitchen bench.
Use an inside voice.
No TV on school mornings.
Children must brush teeth and get into pyjamas before getting "bedtime choices".
All family members must support the Collingwood Football club, or leave home.
You get what you get, and you don't get upset.
Remember to put out the bins on Thursday nights.
Full participation is expected during Shabbat blessings, and this includes guests.
Don't waste water; the farmers need it.
A quick game's a good game.
The house must be tidy before the cleaner comes to clean.
Obsessions, such as martial arts, patchwork quilting, trains and fairies are to be tolerated, nay, respected.
Tickle the mickle is the preferred format for tickling.

Read my other blog like a book

2009-01-12T02:55:00.000-08:00

I recently added a table of contents page to my other blog, Martial Arts and Modern Life, with section headings available from every page of the blog. It should make that blog much easier to read for the someone coming to it for the first time:

The table-of-contents post appears on the left, with chapter headings and links, but the neat "feature" is the table-of-contents that appears on the top-right of my blog, making it easy for me to navigate, and for readers to get an overview and dive in to whatever interests them.

Already I have had some positive feedback about this feature, and I would encourage others to emulate it for the sake of their readers. It seems to make a nice complement to tags, which are a bit more like an index, and archives, which tell you what's new.

The set-up steps in Blogger (it should be similar for other platforms) are:

Invent chapter headings for your blog
Create the table-of-contents blog entry: E.g. myblog.blogspot.com/toc.html, or (nowadays) a page and include your chapter headings.
Tag every heading with using Edit HTML in the blogger editor by wrapping it in anchor tags: e.g.
```
<a name='chapter1'>Chapter1</a>
```
Go through all your old posts and put links to the better ones under the appropriate chapters.
Make a text widget that points to your table-of-contents entry and the chapter headings. The hyperlinks from the chapter-headings take the form
```
<a href="http://www.blogger.com/myblog.com/toc.html#chapter1">Chapter1</a<
```
Place the text widget somewhere prominent.

Maintenance is even easier:

Each time you add a new post that fits your theme, add a link in your table-of-contents post.
Occasionally you may want to add a new "chapter", which involves editing the widget as well, but this should be a fairly rare event once you have your categories straight.

Now I just need to apply the same technique to this blog!

Happy New Year / Kids and Maths

2008-12-31T14:56:00.000-08:00

Happy New Year!

This morning -- January 1 2009 -- Jake and I went for a walk around the park and greeted various joggers and bike-riders and walkers with hellos, often resulting in replies of "Happy New Year!".

On the way back Jake -- who is almost five -- said to me, "Daddy, do you want to hear something that I know that you don't know?"

"Sure", I said.

"There are two fours in eight, and four twos in eight!"

Actually I did know that, but didn't say it, and instead felt very proud, and asked Jake how many twos there are in six, and how many threes. I also asked him how he got to his first result: He "figured it out". So I told him that he was noticing patterns in numbers, and that that is a good thing to do.

Just for the record, without much prompting from me, basically just encouraging him to count forwards and backwards, counting on fingers, tallying, and recognizing written numbers, my boy spontaneously noticed a pattern illustrating not only a feel for division, but also for symmetry, or more specifically the commutativity of multiplication (a*b = b*a always) albeit in this one case. And this before noticing commutativity of addition (a+b = b+a always), and even the trick of "counting on".

I'll take this as evidence that (at least for Jake) encouraging an awareness of numbers and patterns is not a bad way to go. This contrasts with my experience of doing pages of simple sums and subtractions (4+3= ...) at age four, which apparently I enjoyed!

Not a bad new year's present for a dad!

Peter Sbarski has submitted

2008-12-21T20:38:00.000-08:00

Congratulations to Peter Sbarski on submitting his PhD thesis (just in time for Christmas). Peter developed the layout algorithms used in Authink's software, and more besides. His supervisors were Prof Kim Marriott of Moansh University and Austhink founder Dr Tim van Gelder, but Peter was kind enough to also thank me for my help and sometime mentoring:

Dan, I must thank you for all your advice and work that you have put into this thing. I know that my thesis wouldn't be the same without your help. I really do appreciate everything that you have done and I'll always remember it. In fact, I feel so very lucky that I got to work with you. A huge chunk of this thesis belongs to you.

[Quoted with permission.]

It should be pointed out that Peter was kind enough to include me as a co-author on some of the papers that came out of his thesis work, which I appreciate.

Peter is a bright fellow and collaborating with him and Kim has been a pleasure. I wish him all the best, and hope to work with him again one day.

Programming Languages as Cars, Religions

2008-12-17T12:57:00.000-08:00

I owe part of my vanity rank to my contribution to Michael Vanier's amusing If programming languages were cars ... rant:

Ada is a tank. A butt-ugly tank that never breaks down. People laugh uncontrollably if you tell them you drive Ada, but really, do you want to be driving a sports car in a war zone?
Assembly Language is a bare engine; you have to build the car yourself and manually supply it with gas while it's running, but if you're careful it can go like a bat out of hell.
Assembly Language: you are the car.

Basic is a simple car useful for short drives to the local shops. Once popular with learner drivers, it has recently been stripped down to a shell and rebuilt by a major manufacturer, The new version has been refurbished for longer journeys, leaving only cosmetic similarities to the original model. [from Przemyslaw Wrzos]
C is a racing car that goes incredibly fast but breaks down every fifty miles.
Cobol is reputed to be a car, but no self-respecting driver will ever admit having driven one.
C# is a competing model of family station wagons. Once you use this, you're never allowed to use the competitors' products again.
C++ is a souped-up version of the C racing car with dozens of extra features that only breaks down every 250 miles, but when it does, nobody can figure out what went wrong.
Eiffel is a car that includes a built-in driving instructor with a French accent. He will help you quickly identify and learn from your mistakes, but don't you dare argue with him or he'll insult you and throw you out of the car. [From Daniel Prager with some embellishments]
etc. etc.

Now amz (and friends) have been inspired to write: If programming languages were religions.... Not quite as pithy, but possibly more accurate! Cut-down version:

C would be Judaism - it's old and restrictive, but most of the world is familiar with its laws and respects them. The catch is, you can't convert into it - you're either into it from the start, or you will think that it's insanity. Also, when things go wrong, many people are willing to blame the problems of the world on it.
Java would be Fundamentalist Christianity - it's theoretically based on C, but it voids so many of the old laws that it doesn't feel like the original at all. Instead, it adds its own set of rigid rules, which its followers believe to be far superior to the original. Not only are they certain that it's the best language in the world, but they're willing to burn those who disagree at the stake.
C++ would be Islam - It takes C and not only keeps all its laws, but adds a very complex new set of laws on top of it. It's so versatile that it can be used to be the foundation of anything, from great atrocities to beautiful works of art. Its followers are convinced that it is the ultimate universal language, and may be angered by those who disagree. Also, if you insult it or its founder, you'll probably be threatened with death by more radical followers.
C# would be Mormonism - At first glance, it's the same as Java, but at a closer look you realize that it's controlled by a single corporation (which many Java followers believe to be evil), and that many theological concepts are quite different. You suspect that it'd probably be nice, if only all the followers of Java wouldn't discriminate so much against you for following it.
Lisp would be Zen Buddhism - There is no syntax, there is no centralization of dogma, there are no deities to worship. The entire universe is there at your reach - if only you are enlightened enough to grasp it. Some say that it's not a language at all; others say that it's the only language that makes sense.
Haskell would be Taoism - It is so different from other languages that many people don't understand how can anyone use it to produce anything useful. Its followers believe that it's the true path to wisdom, but that wisdom is beyond the grasp of most mortals.
Erlang would be Hinduism - It's another strange language that doesn't look like it could be used for anything, but unlike most other modern languages, it's built around the concept of multiple simultaneous deities.
Ruby would be Neo-Paganism - A mixture of different languages and ideas that was beaten together into something that might be identified as a language. Its adherents are growing fast, and although most people look at them suspiciously, they are mostly well-meaning people with no intention of harming anyone.
Python would be Humanism: It's simple, unrestrictive, and all you need to follow it is common sense. Many of the followers claim to feel relieved from all the burden imposed by other languages, and that they have rediscovered the joy of programming. There are some who say that it is a form of pseudo-code.
COBOL would be Ancient Paganism - There was once a time when it ruled over a vast region and was important, but nowadays it's almost dead, for the good of us all. Although many were scarred by the rituals demanded by its deities, there are some who insist on keeping it alive even today.
APL would be Scientology - There are many people who claim to follow it, but you've always suspected that it's a huge and elaborate prank that got out of control.
Visual Basic would be Satanism - Except that you don't REALLY need to sell your soul to be a Satanist...

Although I have nothing to add -- at this time -- I did enjoy many of the comments on proggit.

Waffles are go!

2008-12-11T02:44:00.000-08:00

My quest for waffles is over. Last Saturday I saw a modern waffle-maker at K-Mart with my beloved and gingies, and -- despite being there to purchase gifts to place under the Wishing Tree, and not stuff for ourselves -- I had to have it. Now it is mine:

The recipe was complicated, including sifting, separating eggs and beating the whites until they stiffened, folding, and -- most challengingly -- leaving the mixture to sit for 10 minutes.

Then you cook each waffle for exactly 3 minutes:

cool them on a rack:

Now cut them up and sprinkle with sugar, Belgian style:

And admire the complexity of the waffle-creation process:

Now enjoy!

Hmmm: They tasted like ... waffles! I.e. Good. The general consensus was that they are even better with ice-cream and Maple syrup. There was so much mixture that we were able to freeze some for later. I think that they should reheat quite nicely in the toaster.

Interesting articles on programming and management

2008-11-21T18:21:00.000-08:00

The following are informative and frequently humorous resources for those of us working professionally in software development:

The Hacker FAQ: Explains hackers to managers
The Manager FAQ: Explains managers to hackers
How to be a Programmer: Answers questions for those at various stages of the programming career-ladder

Anyone who fits the hacker archetype described in the Hacker FAQ may also find The Bipolar Lisp Programmer interesting.

My quest for waffles

2008-11-18T18:35:00.000-08:00

As a child we had an old-fashioned waffle-iron. It was a two-handled affair that you would pour the batter into, close, and then cook over the stove. I favored my waffles with maple syrup and ice-cream.

Now that my children are eating solid food and enjoying occasional Sunday pancake (really crepe) breakfasts, I find myself pining for waffles, and wanting to share the experience with them.

So I am on a quest for a waffle iron, and I am torn: Do I go for authenticity and purchase a waffle iron of metal -- perhaps even an expensive Italian one that brands the maker's-mark into the waffle -- or a modern jaffle-like contraption that promises more consistent results, and easier cleaning?

Yesterday I bought a waffle at the local food-hall, and while adequate and not cheap, it was re-heated and not ideal.

Stay tuned. Meanwhile here is an article about the ancient and noble history of waffles.

Promoted: The Kibitzer becomes the Kibitzed

2008-11-11T12:59:00.000-08:00

Around the start of the month I was promoted from Lead Software Developer to Chief Technology Officer at Austhink Software. [Look ma, I' m a CTO! If only we had an executive washroom. ;-)] I will still be hands on -- designing, programming, pairing, etc. -- but with the new title comes some additional power and responsibilities. In particular, I now have a hand in setting technology strategy plus additional leadership duties.

An interesting effect of the promotion has been that where previously I was the kibitzer -- giving unsolicited and sometimes unwelcome advice -- I have now become the kibitzed! The guys on my team -- Ben and Aaron -- are becoming increasingly assertive in stating to me what they think should be done. And that's fine with me. It seems to me that the allied challenge is to become a better communicator: Both in listening closely to the kibitzs (advice) and kvetchs (complaints), and in clearly articulating the over-arching priorities, so that we can all work together in setting and executing our plans.

Other than that, my motto since making the change has been: "Review, re-focus, and get on with it." The review part has been about taking stock of where we are, the re-focus is about articulating concrete changes in approach, and getting on with it is all about moving forwards.

So I expect that there will be a change tone in future entries, arising from my new perspective at work. OTOH: Whenever I run out of ideas I can always look back over my old blogs for inspiration!

What Ella wants for her 3rd birthday party

2008-11-11T01:38:00.000-08:00

Cupcakes: No icing
Pink icy-poles
Mozzarella
Cheese sticks
Apricots
Snakes
Chocolate frogs
Lollipops
Birthday cake

Cross-promotion

2008-10-02T17:10:00.000-07:00

My patchwork quilt obsessed partner has started her own blog: Patch Andi.

We're a blogging family now!

What's your vanity rank?

2008-09-26T02:37:00.000-07:00

A vanity search is when you type your own name into a search engine.

Now, most of us vanity searchers have learned that we are not alone -- there are pretenders out there using our names! So I propose a new term: "Vanity rank". To determine your vanity rank, simply do a vanity search and find the first link that refers to you rather than some doppelganger.

What's my vanity rank? At time of writing -- using Google -- it is 2 as Daniel Prager, and 1 as Dan Prager.

Please look out for my coming book, "How to boost your vanity rank", Narcissus Press, a subsidiary of Mirror Corp.

Why Scheme rocks

2008-09-16T15:58:00.000-07:00

Scheme is a modern Lisp dialect. It's what I program in for fun, and to learn new stuff.

Why is it so great? In a word, meta-programming. I can bend the language to my will.

For example, I have just added my own tracing to function definitions, without touching the insides of the function. Instead of using the built-in (define ...) I use my own 12-line* macro (define-with-trace ...). Now all I need to do is figure out how to redefine define.

Here is a more poetic endorsement.

* Plus 4 lines of auxiliary code.

Let My Textbooks Go!

2008-09-15T15:57:00.000-07:00

There are three problems with prescribed textbooks:

A generally low standard: Feyman's anecdote. Has anything changed since the 60's?
An inflated sticker price: A NY Times article explains how textbook publishers are like big pharma.
Limited content: So learn how to search the interweb!

Textbooks are starting to be given away for free. One free one that I have bought -- because I wanted a dead leaves version -- "one of the great classics of Computer Science" - Paul Graham.

This is free as in free beer, which addresses point 2. Point 1, the generally low standard, might be helped by more collaborative work on the content, taking a leaf out of the free software movement.

We'll see ...

Unit testing vs Scenario testing

2008-09-08T15:18:00.000-07:00

Miško Hevery gives some excellent advice on designing testable software here, and elaborated here:

Unit Testing as the name implies asks you to test a Class (Unit) in isolation.
If your code mixes Object Construction with Logic you will never be able to achieve isolation.
In order to unit-test you need to separate object graph construction from the application logic into two different classes
The end goal is to have either: classes with logic OR classes with “new” operators.

Here's the explanation / summary:

Asking for your dependencies instead of constructing them withing the application logic is called “Dependency Injection” and is nothing new in the unit-testing world. But the reason why Dependency Injection is so important is that within unit-tests you want to test a small subset of your application.

The requirement is that you can construct that small subset of the application independently of the whole system. If you mix application logic with graph construction (the new operator) unit-testing becomes impossible for anything but the leaf nodes in your application.

Without Dependency Injection the only kind of testing you can do is scenario-testing, where you instantiate the whole application and than pretend to be the user in some automated way.

My emphasis.

Now, this is not to say that you don't need scenario testing, but I have found by bitter experience that trying to mock bits and pieces in scenario tends to be more trouble than it is worth: You end up with large and unwieldy pieces of testing infrastructure.

My current recommendation is that you need to test in both isolation and integration:

For isolation (unit testing) use TDD and dependency injection, or DBC
For integration, use scenario-based testing on the actual application using some kind of scripting interface.

Other specialist tools may be useful. For example, for highly graphic applications it is invaluable to be able to step-through the scenario tests to visually confirm what is happening on-screen. Visual diagnostics are also a great help for this "semi-manual" testing.

Amazon's recommendation system is too good

2008-09-08T14:56:00.000-07:00

Amazon makes it too easy to reliably find -- and purchase -- good books.

The histogram of star-ratings, the user reviews, the cross-referencing with other books bought by people who bought a particular item, and what people ended up buying who looked at all make it easy to track down top books in any given area. Not to mention the access to second-hand books, especially for out-of-print items.

Coupled with the recent strength of the Aussie dollar and the exorbitant cost of purchasing locally, Amazon has proved a recent drain on my finances and a burden to my bookshelves.

So I am resolved: I am not ordering any more books from Amazon for the rest of 2008.

Tickle the Mickle

2008-08-30T17:43:00.000-07:00

The kids and I invented a new game today, called "Tickle the Mickle".

A player announces, "I am the Mickle!", and lies supine (tummy up) on the couch or floor.
Everyone else says, "Tickle the Mickle!", and starts tickling the Mickle.
This continues until the Mickle says "Stop!".
Someone else takes a turn to be the Mickle.

In a competitive game the winner is the Mickle who can endure the most tickling.

Alan Kay on Research into Learning and Teaching

2008-08-24T16:13:00.000-07:00

SecretGeek asked Alan Kay about the paper "The Camel Has Two Humps", and received a fascinating reply. Excerpts:

Notion 1: Good science can rarely be pulled off in an environment with lots of degrees of freedom unless the cause and effect relationships are really simple. Trying to assess curricula, pedagogy, teaching, and the learners all at once has lots of degrees of freedom and is *not* simple.
So for example we've found it necessary to test any curriculum idea over three years of trials to try to normalize as much as possible to get a good (usually negative) result.

Notion 2: Most assessments of students wind up assessing almost everything but. This is the confusions of "normal" with "reality".
For example, in our excursions into how to help children learn powerful ideas, we observed many classrooms and got some idea of "what children could do". Then I accidentally visited a first grade classroom (we were concerned with grades 3-6) in a busing school whose demographic by law was representative of the city as a whole. However, every 6 year old in this classroom could really do math, and not just arithmetic but real mathematical thinking quite beyond what one generally sees anywhere in K-8 [kindergarten and grades 1 through 8].
This was a huge shock, and it turned out that an unusual teacher was the culprit. She was a natural kindergarten and first grade teacher who was also a natural mathematician. She figured out just what to do with 6 year olds and was able to adapt other material as well for them. The results were amazing, and defied all the other generalizations we and others had made about this age group.
This got me to realize that it would be much better to find unusual situations with "normal" populations of learners but with the 1 in a million teacher or curriculum.

Kay gives two examples of quite famous teachers who have written books about their methods:

I found Tim Gallwey [Inner Tennis, Inner Work, etc.], who could teach anyone (literally) how to play a workable game of tennis in 20 minutes, and observed him do this with many dozens of learners over several years.
I found Betty Edwards [Drawing with the Right Side of the Brain] who could teach (again literally) anyone to draw like a 2nd year art student in one intense week.

It is also an interesting social question as to why it is ok to celebrate amazing teachers in film -- e.g. Jaime Escalante in Stand and Deliver -- but not to look more closely at their methods and try to work with them to re-jig teacher identification, training and school curricula.

My Virtual Museum of Modern Art

2008-08-21T16:01:00.000-07:00

You can create your own modern art at museumr.

Science at Home

2008-08-12T14:46:00.000-07:00

In our current home arrangement my kids share a bedroom, and have a separate toy-room. The spare bedroom is my dearest's sewing room, although it often reverts to junk-room state. We use the dining-room as a kind of study.

My son would like a room to permanently set up electric train tracks. The toy room isn't big enough so he uses the floor in the "good room", but we make him pack it up at night.

I have said for some time that I would like a home dojo (martial arts area), preferably in a basement so as not to frighten the neighbours. As something of a homage, I would call it The Dungeon.

Additionally, there is the prospect of "doing science at home". Now, when I did year 12 chemistry I was fortunate to have a skilled laboratory partner, Steve Alcorn, who led the experiments while I took the lead on the calculation. However, my general experience at school and later at Uni. was that lab. work was dull, except on one occasion when I re-designed an experiment to make it work. That was a blast; the creativity and imagination were re-injected.

Reading Oliver Sacks's memoir Uncle Tungsten conveys the joy (and obsessionality!) of designing and performing one's owns experiments. In my case, as a teenager I satisfied that desire in the more abstracted world of exploratory computer programming, but I would like to expose my kids to the more concrete worlds of chemistry, electronics, and -- probably -- robotics first. Biological experiments can wait until they are older!

Apparently chemistry sets don't come with chemicals anymore. Here's a link to The Illustrated Guide to Home Chemistry Experiments, which sounds like a great place to start. Apparently you can get in trouble with the authorities for daring to do Science at home, so perhaps I should secrete "The Lab" behind the Dungeon.

Of course I don't really need a bigger house to do all this great stuff, just time, a little discipline (for cleaning up) and more importantly the patience to wait for the kids to show sparks of interest. Here's a nice story of a parent engaging a child in learning. For now, I'll try to encourage the kids to keep messing around with play-dough and paints, and try not to gripe too much about the mess.

What can go wrong with Agile approaches

2008-08-06T20:43:00.000-07:00

Over the years, most (competent) software developers discover that an iterative approach -- Prototype; demonstrate; modify; demonstrate; rinse and repeat -- is essential for successful software development. In recent years this kind of approach has been formalized and elaborated as the Agile family of methods: XP, Scrum etc.

Here Gojko Adzic reports on a talk given by Henrik Kniberg -- author of Scrum and Xp from the Trenches -- on how software development can be screwed up anyway. He presented a long list of issues that have cropped up in Agile projects and -- interestingly -- had audience members hold up cards to signify how much of a problem each pathology was to them.

A good professional development exercise would be to go through a subset of the list with red/green/cards, and talking about the whys, wherefores, and possible remedies.

My Suggestion for a Privacy Statement

2008-07-29T21:19:00.000-07:00

Most privacy statements for web-sites include something about the use of cookies. Recently I was peripherally involved in the re-drafting of one such section.

No, not that kind of cookie

Here's my "draft", which could be used as a honeypot to see if anyone ever reads these things:

We do not use cookies to determine the identity of individual users, unless you log in, in which case we track you using all available means, including, but not limited to: satellite, your mobile phone, secret service operatives, cookies, ice cream, fudge, radio-receivers implanted in your molars, and miniature remote-control insects. Depending on what we catch you doing we may use this information for blackmail or our own amusement at in-house video-nights. However, rest assured that we do not permanently store any of the gathered information.

Naturally, this is not the version that we are going forward with.

Some excellent OO programming tips (and discussion)

2008-07-24T22:12:00.001-07:00

Some classy advice from munificent on a proggit thread:

Do not copy and paste. Move code around, but don't duplicate it. Disabling Ctrl-C on IDEs would improve the world's programming better than anything I can think of.
Decouple decouple decouple. Of all of the things you can do to improve code, reducing coupling will, by far, have the greatest impact at making your life better.
Don't store what you can calculate. The fewer member variables, the better. Avoid storing any redundant data unless you want to fix synchronization bugs forever.
Make classes immutable when possible. It's easiest to use something you can't break.
Don't get too excited about inheritance. If you aren't using polymorphism, you probably don't need to use inheritance.
Use all of the features of your language. Delegates (function pointers), static (i.e. non-member) functions, etc. are just as useful with OOP as within straight procedural.
If you have a hard time naming a class, it's poorly defined. That being said, don't let lack of a name stop you, you can always find and replace later. Likewise, rename classes if their purpose changes over time.
Never call anything "FooManager". Objects are supposed to manage themselves. Get rid of the manager and put the code in Foo.
Don't be afraid to make little classes. Making a class just to bundle a couple of function args is perfectly fine. A few months later you'll find you've all sorts of other usefulness to it.
Refactor constantly. Coding without refactoring is gardening without weeding and pruning. You can't just keep packing new plants into your yard.

There is some good further discussion and qualifications in the sub-comments.

Alan Kay's Reading List

2008-07-24T20:03:00.000-07:00

Alan "Smalltalk" Kay gives a list of books for people interested in the ideas and philosophies that influenced Squeak. It looks like a good list for anyone interested in software invention.

I have read a smattering of the books and some other works by authors on the list, and they were generally outstanding. I will try to sample the remainder (over time).

A witty remark

2008-07-23T20:23:00.000-07:00

The other day I was standing in my bedroom, and went to take a step, only to find that I could not. My son, Jake, aged 4 1/2, was lying full length and prone on the floor with arms extended and both hands securely clamped around my left ankle. Andi looked on. This had happened before.

Jake ordered me to drag him along the floor: "Walk!", came the command from below.

"I refuse to walk anywhere while there's a manacle attached to my leg", I replied.

"That's not a manacle; that's a boy-acle!", said my beloved.

Laws of Logins

2008-07-22T15:26:00.000-07:00

Privacy issues aside, when it comes to logins, I want convenience.

When using a web-page that provides a service, I want it to:

Allow me to try or taste the service without entering a username and password (or I won't it use it).
Never supply username and password if the service is once only (or I won't use it).
Allow me to login and use a nice administrative interface if it is a site that allows me to create content. For this, I not only accept having to supply login details; I want to be able to login.

Of course having to remember multiple logins for multiple sites (point 3) is a PITA. Can OpenID help with this?

Order-dependence of design decisions

2008-06-22T17:54:00.000-07:00

When the proggit community was asked for their best piece of Best piece of insight for computer programming/software engineering? some excellent responses were elicited, including this one from hamsterboy:

The quality of the design of a piece of software depends on the order in which you make the design decisions. 5 years from now, the earliest decisions will have the most far-reaching consequences, and will be the most difficult to re-think.

This can be taken incorrectly as an indictment of incremental approaches or, more acutely, as justification for periodic re-design.

Recently I have been working on a port /re-design of a 2.5 year-old product and it has been an absolute pleasure to be able to take advantage of the insights learned the first time round.

Where did the red hair come from?

2008-06-11T15:49:00.001-07:00

Here's a picture of my kids, both of whom are gingies:

Ella (left) and Jake

Since neither I nor Andi (Mum) is a red-head we are incessantly asked "Where did the red hair come from?"

Popular answers include:

Postman Pat
Alien abduction
They are freaky mutants

Incidentally, none of their grand- or great-grand-parents were red-heads, but they have a few carrot-headed cousins.

Apparently the genetics of red-hair is not simple. In particular, it is not just a case of a recessive gene hiding away for a few generations.

Andi and I are not planning any further children. I have suggested that we try for a non-redhead, but the danger of a third gingy has proven to scary.

Jake's 10 Commandments

2008-06-11T15:01:00.000-07:00

As part of this year's Shavuot celebrations at my son's kindergarten every child devised his or her own version of the 10 commandments. This is what Jake came up with:

Jake's 10 Commandments

No jumping on other people.
After eating at kindergarten please have a drink to wash down the food that is stuck in your teeth.
No poo-ing in your undies.
I will not bend my glasses.
My sister cannot slap me.
I will not take the mattress off my bed and throw it on the floor.
Do not slam the door on somebody's fingers.
No touching the stove when it is on.
No screaming.
No tipping water out of the bath.

Signs of Good Design

2008-05-27T15:17:00.000-07:00

It is a good sign when something you design solves problems not originally envisaged. This indicates depth and robustness.

Another good sign is when a third party of high standing makes a recommendation.

Both these signs are apparent in the increasing adoption of the Erlang language and libraries for distributed computing problems. Originally designed for telecommunications software, Erlang is now being used by Amazon, Facebook, and others as part of their infrastructure.

Also, Steve Vinoski, an authority on CORBA, an older technology for distributed computing, has been singing the praises of Erlang for largely "getting it right". In response Joe Armstrong (inventor of Erlang) has thanked Steve for going down the wrong path and living to tell the tale. Here's Joe on Steve, and Steve on Joe.

I hope that everyone working in distributed computing can take note of the lessons that Steve (and Joe) learned the hard way, without necessarily repeating all the hard yards.

Remember: It is always a good time to learn from other people's mistakes (and your own).

Got Art?

2008-05-22T17:03:00.000-07:00

Last night my beloved and I splurged on a piece of modern art. In the past we've made our own -- in a "Jackson Pollock" style -- but Andrea spotted this work by local artist Gary Solomon while driving home yesterday:

Go 'Pies!

A screech of brakes, much excitement, a quick discussion of finances, and we're newly minted patrons of the arts. Now we just need more wall-space (and money) to grow our collection.

Programming Yin and Programming Yang

2008-05-15T15:23:00.000-07:00

Q: Why is programming fun?
A: It is a form of play and exploration in which a "one-time" "small" effort (writing the program) yields a large reward (the program does something). It combines the artistic joy of creation with the scientific reward of nutting out a puzzle.

Q: Why is programming hell?
A1: When the program fails to produce the expected results a diagnostic process of "debugging" follows. As the program grows in size and power and (hence) complexity, this debugging phase dominates the programmer's time, and brings mainly relief rather than reward.

A2: When requirements change the program may need to be re-jigged to accommodate them, and this re-jigging, similar to debugging lacks the immediate rewards.

* * *

So, to increase the rewards of programming -- and incidentally productivity and profitability -- techniques are sought to reduce the dross (debugging and re-jiggering), and increase the rewards (features and elegance).

On the Yang side of programming I include design, architecture, algorithm invention, and implementation of new features.

On the Yin side I include practices like Design By Contract (DBC), Test Driven Development (TDD), and Continuous Integration (CI). These provide no up-front reward, but pay for themselves over time.

Interestingly, all three involve using programming to write better programs. DBC and TDD may be regarded -- with some licence -- as simple forms of meta-programming. We are writing program fragments to help test our programs. Also, the act of making tacit assumptions explicit helps us to think about and hence improve the underlying design.

By putting in place these effective (Yin) measures, we can be bolder (Yang) in adding new functionality, having built a software safety net as we step forward.

True meta-programming, writing programs that write programs brings us back to the Yang side.
We are now truly working at a higher level of abstraction, with correspondingly more leverage, but when bugs appear in our meta-programs the debugging gets harder too ...

Fred Brookes on Online Collaboration

2008-05-12T15:24:00.000-07:00

DL Weinreb, one of the co-creators of Common Lisp, took some notes at the OOPSLA 2007 conference. One of the talks was by given by Fred Brooks:

Fredrick Brooks Jr., author of the classic book “The Mythical Man-Month”, talked about telecollaboration. Most of the talk was about collaboration itself, and under what circumstances it’s a good thing: not always! His main point is that collaboration is great for determining system requirements and brainstorming about possible approaches, but that you really need a single system architect in order to achive conceptual integrity. The system architect can delegate parts of the architecture to others (e.g. the user interface czar), but he distinguishes sharply between delegating design (OK) and sharing design (not OK).

Readers of The MMM, will not be surprised by Brooks's reiteration of the need for a single designer to ensure a unified vision, but it's nice to have strong position brought to light in a new context.

For me, Brooks's pronouncement raises a couple of questions:

To what extent does his advice apply to non-software enterprises?
To what extent should collaborative software endeavour to encourage "good practice" through constraining its users?

Algorithms vs Architecture

2008-05-05T15:42:00.000-07:00

There are many facets to software design. Some, like user-interface design, are apparent to the end user. Others take place almost entirely under the hood. These are the bones on which the software is built.

Two significant under-the-hood aspects are algorithms and software architecture.

Algorithms form a major strand of computer science. They are concerned with
the nitty-gritty of getting the computer to do stuff. The major aspects of an
algorithm include: what it does, its domain of valid inputs, and its time- and
space-efficiency.

Software architecture, on the other hand, is concerned with the high-level structure and conventions of a software system, and is more of a topic for industry than academia. Good architectural choices contribute to the overall performance, resilience, and extensibility of a system.

We need both! And interestingly, you neglect either one at your peril.

For example, recently when we noticed a significant slow-down in performance the issue turned out to be an architecture-algorithm interaction. While the algorithm was O(n^2) in time, an imperfection in the architecture led to it being executed as each item was added to the structure, making it effectively O(n^3), and correspondingly sluggish.

As usual, when the problem is tricky to track down, it is often due to the interaction of two separate-seeming factors.

Just a Little Bit Proud

2008-04-16T14:41:00.000-07:00

What with the recent passing of Charlton Heston a newcomer had to step in and play the lead role of Moses in our local kindergarten's model Passover Seder* later today, and my son Jake has scored the honour, leaving me just a little bit proud.

Charlton Heston as Moses

Jake as Moses

Here are the lyrics to one of the more amusing Passover songs that the children will be singing today, recalling the second of the ten plagues that Moses called down upon Pharaoh (and the Egyptians):

The Frog Song (Shirley Cohen)

One morning when Pharoah awoke in his bed
There were frogs in his bed, and frogs on his head
Frogs on his nose and frogs on his toes
Frogs here, frogs there
Frogs were jumping everywhere.

Fittingly, both of his grandfathers will be in attendance, and I look forward to hearing reports, seeing photos and -- technology permitting -- video of Jake with his "overflowing beard" in action.

*The Passover Seder is a special meal in which the story of the Jews' escape from slavery in Egypt is retold and celebrated with food, wine and singing. The model Seder is the kids' version where they learn how it all works. It's a bit like a Christmas pageant, but with more food.

Interview Questions for Candidate Software Developers

2008-04-14T15:10:00.000-07:00

Basically I am looking for evidence of the following

Smart
Gets things done
Communicates effectively
Passionate about software development
Has a solid technical foundation
Quick learner
Cultural fit (sense of humor, down to earth, enjoys working with others)

In the past I have written down my questions for candidate software developers 0n scraps of paper, which get lost. Here are some somewhat open questions:

Work history

Why are you interested in this job / company?
Why now?
Tell me about a tough lesson from your last job.
What are the key things that you have learned about maintaining and enhancing a pre-existing software system?

Object-Orientation

What is the difference between a class and an object?
What is an interface? Why are interfaces useful?
What is inheritance? Compare and contrast single and multiple inheritance.

Programming Language Theory

What is recursion?
What is an advantage of iteration over recursion?
What is an advantage of recursion over iteration?
*What is a closure?
*What is a continuation?

Agile (assumes some [claimed] knowledge)

Have you worked in an "agile team" before?
Have you read up about Agile / XP / Scrum?
Explain difference between waterfall and iterative development
Explain some of the XP practices (e.g. pair-programming, test-driven development, continuous integration, re-factoring)
What's Scrum about? How does it work?

Testing

Difference between manual and automated testing?
Which kinds of automated testing have you used?
In which areas is it trickier to test automatically
Test first or code first? Why?
*What is Design By Contract?

Motivation

Favorite things about working in IT / software development?
Worst things?
What do you want to learn more about?
Let me solve it and report back, or let's figure this out together?
What are the key elements that make for a good team?
Tell me about a cool tool, language, or technique that you have learned and applied recently.
Favorite and least favorite programming languages that you have used professionally?
Why?
What's wrong with [favorite]?
What's good about [least favorite]?

Of course, a lot of the interview is about gauging the tone (affect) of the response and following up on interesting responses.

Additionally, I usually do a pair-programming exercise / challenge with technical candidates, usually with a little design phase and some test-driven development. This tells me a lot, but it is time-consuming and can be quite draining (especially if it doesn't go well!).

Cross-ferretization

2008-04-06T14:29:00.000-07:00

Cross-ferretization, n. The art of ~~stealing~~ ferreting out ideas from other fields and applying them to one's own.

In programming, there are many generic job descriptions:

programmer
software developer
software engineer
software architect
computer scientist
hacker
etc.

Each of these has its own connotations, some overlapping, some contradictory.

Recently I have been delving back into (physical) architecture, and finding out a bit more about that field.

(Physical) architects are the generalists in a once-unified field that has splintered into civil engineers, draughtsmen, builders, interior designers, etc. Consequently their training delves into many fields, and in practice they work with many specialists, especially on large projects.

So it seems reasonable that there is a role for (software) architects in the (virtual) world, although such titles seem to be largely self-bestowed and not really as well-defined as (physical) architects.

Another reason for the interest in architecture in software development is the influence of Christopher Alexander and his notions of patterns and pattern languages on programming. This gave rise, largely via the famous Gang-of-Four book, to the notion of patterns in software (although the notion of pattern languages) was not as widely imported.

For what it is worth, Alexander's original writings have always resonated with me in a way that the Gang-of-Four's have not. So the other day when I spied an attractively packaged little book aimed at (physical) architects and students of architecture, entitled 101 Things I Learned in Architecture School by Matthew Frederick, I purchased it with little hesitation.

Quick review: "101" is not just a book for architects, but for anyone with an interest in any kind of design. Many of the "things" are of general applicability-- I especially like #29, about the importance of being process- rather than product-oriented, and #45, which contrasts simplicity with complexity and informed-simplicity. Such of the ideas are really very general. Others are specific to architecture, either practical points or theoretical tidbits, often admitting useful analogies. Each thing is accompanied by an illustration.

Every field needs a book like this.

Bit rot vs Re-usable code

2008-03-26T14:37:00.000-07:00

The intellectual property in a software company is diffuse. The explicit IP can be found in patents, papers, documents and, above all, the code base. The tacit IP exists in people's heads.

It is the tacit IP that allows for innovation and change. Indeed, a good way of understanding the possibility of change is the extent to which the maintainers of the software have a theory of how it works. If they do, they can change and extend it. If they cannot they are likely damaging the conceptual integrity of the code-base.

In The Worthlessness of Code James Turner advocates regularly rewriting to ensure that the software development team understands what they are working with, and in-particular, so that the original designers effectively refresh and transfer their knowledge to new hires.

In the comments the rebuttals of "continuous re-writing", and "re-usable code" are raised. Personally, I sympathize with Turner. I used to have a motto: Before re-use, use. This mocked the scenario of people trying to writing libraries or frameworks that would be used multiply, before being deployed successfully even once. Oy! The better alternative is to extract, abstract and generalize after an initial success or two.

What about libraries? The good ones do have a long life. This comment from the Reddit comments on Turner's article draws an important distinction:

How about "reusable code is an asset, single-use code is a liability"?

I like this idea. There is the abstracted, cleaned stuff that ends up in libraries, and gets re-used, and there is the more scripty stuff that glues things together and gets the short-term job done.

This raises the possibility of a new, somewhat informal metric: Ratio of multiple-use (quality code) to single-use (get-it-done code).

What makes X hard?

2007-10-18T15:09:00.000-07:00

Mark Guzdial has written a nice article, What makes programming so hard?

But I say, "Programming: Easy. Dancing: Hard." What he is really talking about is the bimodal nature of skill acquisition. In many areas: Some people really get it; and others don't get it at all, and then there is the group in the middle who kinda get it.

Of course this, split is not accepted in certain fundamental skills: Talking, walking, self-feeding, toileting, where only those with significant disabilities are excused a reasonable competence.

In fact, everyone will find many things hard and many things easy. For example, when I audited a drama subject as part of a teaching degree I found a bunch of (lovely) people who united in their terror of mathematics. In my mathematics subjects, I am sure that I would have found some who felt the same way about getting up on stage.

So what are the elements of (basic) programming?

* Composition
* Decomposition
* Visualization
* Precision and clarity
* Use of and acquisition of formal language
* Memory
* Planning
* Logic
* Numeracy

Deficiency in any of these is likely to lead to frustration. But I maintain that there are two qualities that are necessary for any kind of learning:

* Wanting to learn X
* Patience when an element of X does not come easily

Another factor is having learned something in the past which interferes with the new area of learning. Examples:

* Tennis requires a firm wrist on impact; squash a flexible wrist
* Riding a bike caused me to almost throw myself off an adult-sized trike
* My English grammar makes it hard for me to adapt to Hebrew
* "You can teach anyone Lisp in 1 day, but it takes 3 if they already know C" (the use of parentheses is radically different)

If someone really wants to learn something, and is patient and quietly determined, and has access to an instructor who can help in the basic areas, learning is possible, and may be surprisingly fruitful.

One test of a dance teacher is whether (s)he can teach someone who lacks a sense of rhythm or is uncoordinated can teach these fundamentals, not just so that they can be applied in learning dances, but are transferable to other areas.

Similarly for other teachers.

How many boys? How many girls?

2007-09-17T20:55:00.000-07:00

I hadn’t heard this one before, but I like it a lot:

In a country in which people only want boys, every family continues to have children until they have a boy. If they have a girl, they have another child. If they have a boy, they stop.

What is the proportion of boys to girls in the country?

Apparently used as a Google interview question (not that I’m a great fan of puzzle-based interviewing).

My long solution first

Distribution of families as proportions of all families in the country:

½: B
¼: GB
1/8: GGB
1/16: GGGB
etc.

Let F be the number of families.

How many boys?

Since every family stops after they get a boy the number of boys is F.

Alternatively, we can count the contributions of the different families:

Total boys = F x (½ + ¼ + 1/8 + 1/16 + ...)

This demonstrates that the infinite sequence

½ + ¼ + 1/8 + 1/16 + …

sums to 1, which is also apparent if you stand 1 meter from a wall and 50 cm then 25 cm etc., etc.

How many girls?

Again we sum:

Total girls / F = ¼ x 1 + 1/8 x 2 + 1/16 x 3 + …

= 1/4 + 1/8 + 1/16 + …
+ 1/8 + 1/16 + …
+ 1/16 + …
+ …

= 1/2 x (½ + ¼ + 1/8 + 1/16 + ...)
+ 1/4 x (½ + ¼ + 1/8 + 1/16 + ...)
+ 1/8 x (½ + ¼ + 1/8 + 1/16 + ...)
+ …

= 1/2 x 1
+ 1/4 x 1
+ 1/8 x 1
+ …

= ½ + ¼ + 1/8 + 1/16 + ...

= 1

So, Total girls = F

Solution

Equal numbers!

Simplifying assumptions?

Birth rate of 50-50

No multiple births
Large population
No account made of multiple generations

Even without these assumptions, I would guess that the solution roughly holds.

Simple solution

Each child born has a 50-50 chance of being a boy or a girl. Each birth is independent, and not influenced by decisions of this, or any other family, so naturally half are boys and half are girls.

What's important?

2007-09-16T16:58:00.000-07:00

Computer scientist and mathematician Richard Hammond -- he of the Hamming Code -- used to ask his colleagues two questions. In order:

What the most important issues in your field?, and the follow-up
Why aren't you working on those?

Often this induced a cold-shoulder response, but others were grateful for the nudge.

I have been meditating on what the equivalent question should be in a business, as opposed to Science. My tentative questions are:

What are the most important issues facing our customers?
Why aren't we working on those?

From this it follows that deeply understanding our customers' issues is of paramount importance.

Academic Cross-Training

2007-08-26T15:03:00.000-07:00

Cross-training is not a new idea.

In most professional sports cross-training is incorporated into the usual training regime. Although weight-training and swimming are popular there are more exotic options around. Some Australian Rules footballers have even dabbled in ballet.

In cultures that emphasize the development of the individual as well as excellence, breadth and depth are valued. And for those who like the etymological definition of philosophy -- love of learning -- this is a bit of a no-brainer.

Now, if you are focussed on a narrow goal over a wide-ranging journey the diversions of breadth may prove a waste of time. But if the converse holds you will find that there is much to learn by exploring other disciplines. Here's what happened when physicist Richard Feynman ventured into biology.

If two academic disciplines are dealing with similar material at a deep level, chances are that each has something to offer an individual who crosses over from the other side.

Of course forcing everyone to compulsorily study X, usually leads to resentment from a significant proportion of those so conscripted, so when I say should study, I really mean should be encouraged to study.

In terms of excellence, someone should make a list of people who have achieved excellence after switching fields.

* * *

In sports, it is well-known that gymnasts do well after switching to diving and ski-jumping. From this I infer that gymnastics teaches transferable skills.

What are the nominations for the gymnastics of academic disciplines?

The Programming Djinni Grants Wishes

2007-08-23T15:43:00.000-07:00

As a commercial product develops the wish-list grows longer and longer. User suggestions and feedback are collated and prioritized. Pretty soon you have a very large list.

The tragedy of the C cases
Here's the problem: Lots of worthy but little items are continually pushed to the bottom of the pile, by the latest big feature.

I call this "the tragedy of the C cases". These items of functionality may languish, if proper discipline is respected, never bubbling to the top.

There are disciplined ways around this use Scrum and XP style planning, but these require buy-in from the non-programmers and may not be achievable within your organization.

The magic approach
Here's a simple and fun alternative for a small company or department: One day per month -- customarily on the 23rd (or the nearest weekday) -- one or more programmers turn into djinnis who attempt to grant reasonable and achievable wishes to one lucky person in the company.

This breaks up the usual routine (a good thing as per the Hawthorne effect), is engaging for the lucky person -- who sees some immediate results -- and it is also good for the programmers, who get the satisfaction of working directly with a tangible person for a change rather than through a mediated priority list. And the software gets nicely polished.

Try it: See how you go; let me know.

Re-write or re-factor?

2007-08-21T20:59:00.000-07:00

On individual projects I have usually found that a re-write leads to smaller, cleaner, faster solutions.

I attribute this to learning acquired from the previous attempts/versions, which I can incorporate in the form of improved abstractions and better trade-offs subsequently.

Some re-use of "golden nuggets" from earlier iterations may also be possible, and is certainly desirable.

Some lessons learned can be incorporated incrementally through re-factorings, but there are times when incremental improvement takes you to a local maximum and traps you there.

On big commercial projects other considerations come into play. Until the new code-base is up you need to contend with the cost of parallel development, and this period will be longer the greater the legacy. Unless, of course, your new abstractions are brilliantly efficient, and/or you can cut away a lot of stuff that was not needed.

Once a project is sufficiently large, given finite resources, it may eventually be too late to ever re-write!

Here's some more useful discussion by Adam Turoff on these issues prompted by survey question by Ovid.

Is Law a Branch of Computer Science?

2007-08-21T15:36:00.000-07:00

I studied Law as well (as Science) early in my University career before relinquishing it on account of near-terminal boredom during Contracts (the content of the first third of which ironically proved quite useful to me subsequently).

I remember a visiting lecture by a Government draftsperson, whose job it was to draft legislation. He also happened to be blind. Aha, I thought, this is why legislation is so appallingly structured. That was undoubtedly unfair.

Later I came to the view that lawyers should study programming in order to learn how to structure large descriptions about processes and contingencies.

Now, Dave has come along with this brilliant comparison of legal language and programming languages. It is funny because there are several truths in there.

So, perhaps in the 21st century it is time to include a compulsory "programming for lawyers" unit, along with "legal process" as an introductory subject?

This would extend the wider view of Computer Science as a Natural Science, to cultural endeavours such as Law.

Calculus? Which Calculus?

2007-08-20T15:14:00.000-07:00

In high school and University I learned Calculus, by which I mean the Differential and Integral Calculus of Newton and Leibniz, and their extensions. I do not think that I really grasped the meaning of a continuous function until I studied metric topology.

I like calculus, I have used it professionally, and it is a glory of the modern age, but I do question the cost/benefit of teaching it to millions (billions?) of children on account of its difficulty.

What makes calculus hard?
I would say the relatively high level of abstraction, and in particular becoming comfortable with with either limits or infinitesimals (hello: non-standard Analysis). These things strain our intuition.

Why is calculus taught in high-school? My guesses:

It is essential for physics and engineering, and other quantitative fields
It is very beautiful and powerful (but you will not see that at high school)
It is challenging
It has a filtering effect on students
Tradition

Since it has to be re-taught at College / University, I wonder whether it might be time to start teaching other Calculi in high school, just to mix things up a bit.

Perhaps a progressive school could hold a "calculus bake-off" and try to gauge the suitability and broad benefits of teaching and learning the various calculi?

Which other calculi could be taught?
Some might opt for the predicate calculus (also known as first-order logic), but my vote goes to the lambda calculus, which is fundamental to the theory of computing, and useful in practice. In fact there are computer languages such as Scheme (a Lisp dialect), ML, and Haskell that are essentially souped-up forms of the lambda calculus.

And if high-school sounds a bit late to get started with such an important subject, here is a game designed for eight year-olds that introduces the essential ideas.

There is no such thing as Computer Science

2007-08-16T15:35:00.000-07:00

Not my words, but from a rather enjoyable rant, What's wrong with CS research. Here's the bit containing the best quote (my emphasis):

So here's the first thing that's wrong with CS research: there's no such thing as CS research. First, there is no such thing as "computer science." Except for a few performance tests and the occasional usability study, nothing any CS researcher does has anything to do with the Scientific Method. Second, there is no such thing as "research." Any activity which is not obviously productive can be described as "research." The word is entirely meaningless. All just semantics, of course, but it's hardly a good sign that even the name is fraudulent.

When we look at what "CS researchers" actually do, we see three kinds of people. We can describe them roughly as creative programmers, mathematicians, and bureaucrats.

If only he had claimed that there was no such thing as Science, now that would have been a fun proposition to explore!

Learning about (Computational) Monads

2007-08-12T15:49:00.000-07:00

I am interested in acquiring programming idioms -- or if you like patterns -- that facilitate a clear and disciplined approach to organizing state. As applications grow large and certain operations transform state in a large-scale fashion, it becomes harder to understand and modify program behavior.

Perhaps monads offer a better way, but I don't really get them yet ...

What are Monads?

I think Leibniz invented the term monad to describe some kind of indivisible fundamental entity in his philosophy: Presumably the term atom was too Greek for him. Anyway: I do not mean philosophical monads, or biological monads, or mathematical -- category theory -- monads (although now we are getting warmer).

Right now I mean computational monads, the ones so beloved of Haskell programmers, but potentially of use elsewhere.

A monad is a family of types M t, based on a polymorphic type constructor M, with functions

return :: t -> M t
(>>=) :: M t -> (t -> M u) -> M u

satisfying

return a >>f = f a
m >>= return = m
m >>= (\a -> (f a) >>=g) = (m >>= f) >>= g

This definition gave me flashbacks to Pure Mathematics Honours (4th year University) where I encountered some classes so abstract as to seem totally detached from reality: "Hello Banach Spaces and Algrebras!"

How to get it

But having survived a mathematics education and having a ridiculously high sense of self-efficacy I know how to get through this kind of obstacle. There are two methods:

Abstractions first: Treat this as a game where the rules are given, and play with them until they become familiar and seem natural.
Empirical approach: Walk in the footsteps of the discoverers by building some practical experience first, so that the abstractions begin to make sense.

Better still, work from both ends. Anyway, both approaches require doing, as opposed to reading, and I am starting with the following tutorial:

You Could Have Invented Monads! (And Maybe You Already Have)

which seems to be helping, and belongs to the latter camp.

More later ...

Functional Programming Interest Group

2007-08-09T14:22:00.000-07:00

An idea has been slowly germinating in my mind: Try to start a new special interest group (SIG) meeting in Melbourne once a month, but also with a virtual presence.

I have been working slowly through Abelman & Sussman's Structure and Interpretation of Computer Programming (SICP) and exercises, the MIT classic "introductory" text, but would like to share the experience. The great thing about SICP is that it is free online, as are accompanying video lectures -- the first was inspirational, but subsequently I have relied on the text. The tools are available online and free. The language used is Scheme (a teaching/research Lisp), but it's the ideas that come through.

There are other books out there which promise to capture exciting ideas using various f.p.-ish languages as vehicles:

Hudak, The Haskell School of Expression
Armstrong, Programming in Erlang
Siebel, Practical Common Lisp (text available online)

I believe that languages such as these are worth studying for the ideas that they develop:

Haskell: Lazy evaluation, monadic computation, mathematical modelling, and more ...
Erlang: Practical, reliable, massive parallelism, ...
Lisps: Code-data duality

I am also interested in F# (as the .NET representative of the ML / OCAML) family, but am waiting on the publication and review of more books. [Forgive me for leaving Smalltalk, Forth, plus the various languages du jour off my list: There may well be too many already.]

Other probably books worth looking into:

Graham, On Lisp
Norvig et al, PAIP and AI: A modern approach
Kiczales, The Art of the Meta-Object Protocol
Sussman and Wisdom, Structure and Interpretation of Classical Mechanics (text available online)
Doets and van Eijck, The Haskell Road to Logic, Maths and Programming
Okasaki, Purely Functional Data Structures

Of course these are just some highly rated books, and not the literature, but my objective here is to survey some of the more mature parts of field; the leading edge can wait.

It's all about the joy of new and ongoing learning; with the bonus of becoming more skillful, productive, and having a chance of successfully working with the coming generation of massively multi-core machines.

I would be interested in hearing expressions of interest, suggestions for format plus any experiences and tips from anyone involved in such groups.

XML and ASN.1

2007-07-22T14:34:00.001-07:00

In 2002 -- 5 years ago! -- I spent a year working with Steven Legg on establishing a decent mapping between ASN.1 (the standard for directory structures) and an appropriate encoding in XML. Since then I have gone onto other things, but Steven has continued to work away and last week this work reached IETF request for comment status:

        RFC 4910


      Title:      Robust XML Encoding Rules (RXER)
                  for Abstract Syntax Notation One (ASN.1)

      Author:     S. Legg, D. Prager

      Status:     Experimental

      Date:       July 2007


Congratulations, Steven!

Parsimony in Design

2007-07-10T16:27:00.000-07:00

William Clinger writes in the introduction to the revisions to the Scheme programming language standards (my emphasis):

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.

It would be great to be able to similarly say:

Applications should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Rationale demonstrates that a small number of rules for forming structures, with minimal restrictions on how they are employed, suffice to form a practical and efficient application that is flexible enough to support most of the major decision-making paradigms in use today.

Step 2: Make it so!

Taking stock

2007-07-02T15:44:00.000-07:00

I have been working at Austhink now for a little under two years. I am not sure what my employee number is, but it is less than 10.

My job title says "Senior Software Developer", but Austhink is or was a start-up, and at a start-up everyone chips in where-ever they can. What have I actually been up to?

Project Management / Team Leadership

I have been the senior hands-on guy in an Agile Team

Estimating and clarifying use-cases / user stories
Mentoring other team members (and learning from them too), largely through pair-work and mostly daily meetings
Working with Andy Bulka -- our Technical Director -- to create and sustain an effective and productive atmosphere

I have acted as second-level support

Software Design
I have contributed to the detailed design Austhink's flagship product, Rationale, and associated licensing system. Examples of my touch include my on-going crusade against modes, and searching for simplifications, such as the use of an integrated page-preview instead of a separate print-preview window. And let us not forget the humourous messages that appear on start-up.

I have made many more suggestions and performed many more experiments than have made it into the final product, but I believe that the objective is creativity and net output, rather than high hit rate (but lower output).

Architecture
I have made several key contributions to the architecture of the software including:

Researched options and made technology recommendations. E.g.

Make: The development of a home-grown graph visualization layer (not using Windows Forms) rather than building on top of a third-party product.
Buy: The purchase of DotNetBar's Office 2007-style Ribbon Interface tool rather than using more traditional Windows menus, in early 2006

The use of a programming language syntax (Python) for our file-format -- instead of the more obvious choice of XML -- an idea borrowed from Lisp which has provided several dividends:

Our API became our file-format, rather than a separate interface
Identical format is used for copy / paste
Allowed an elegant solution (also mine) to the problem of forward-compatibility (i.e. opening up a file from a later version of the application in an older copy of the software leads to graceful degradation, including an error report)

Found a way to combine Windows drag-and-drop with our own system (almost, but not quite seamlessly)
Designed a functional-programming style animation sub-system that is being incrementally introduced into Rationale
The extension of the Command Pattern with nestable Begin and End "blocks" to solve the problem of placing compound expressions on the undo/redo-stack that effectively solved the problem of making necessarily sequential multi-step actions easily undo-able and re-doable in a simple fashion.. This was a considerable improvement on our previous "solutions" which were slowing development and increasing complexity.
The use of digital-signing as part of our licensing-system

Software Implementation

Have taught and coached the use of effective techniques such as Test-Driven Development, Design-by-Contract, and Refactoring to generate a fairly robust, efficient and featureful product in quick time.
Have written or co-written much of the algorithmic code myself, especially in the advanced aspects of the workspace area (drop-zones, overview window)
Have managed to stay out of some areas to allow junior colleagues some freedom to develop without "constant" interference
I have found and fixed or worked around several nasty bugs, including one doozy in the Microsoft's .NET framework

Intellectual Property

I have helped liaise and collaborated with our PhD student Peter Sbarski on his algorithmic work
Invented a means for drawing "organic edges" used in Analysis Mode
Invented a repulsion algorithm (in conjunction with Ben Loft)
Invented a way to relax the Picture Rail Principle (which Peter has since generalized)
Helped draft a patent application

Business Stuff

Suggested simplifications to business processes, especially to licensing. E.g.

Observed that we did not need to define a separate product from upgrading ReasonAble users, but could use the Coupon system instead

Entered the winning suggestion for the name of the monthly Rationale newsletter, Ratatouille
Monitored the web for relevant trends (i.e. read reddit and Y-Combinator news :-)

People Stuff

Assisted the Technical Director interview for permanent staff and contractors
Initiated the tradition of bi-weekly lunches in Lygon Street
Contributed to the Rationale mailing list
Supplied festive food (e.g. cheesecake) on culturally significant occasions
Hosted the 2006 Austhink X-mas party

So that is some of what I have been doing for the last two years. On the personal side I became a father for the second time, received my second-degree black belt in Jiu-Jitsu (and first-degree in Judo), continued to run my martial arts club (now in its third year), started two blogs, and begun to develop a very basic competence in spoken Hebrew.

Next stop is to plan a bit of what I would like to do in the next couple of years.

Goal #1: Completion of toilet training.

The Medical Model of User Feedback

2007-06-24T14:48:00.000-07:00

From a Business Week interview with Clayton Christensen, author of The Innovator's Dilemma:

In The Innovator's Dilemma you warn that the maxim "staying close to your customers" can lead you astray. Wouldn't a cursory reading of the book say "don't listen to your customers?"

You're exactly right. The cursory reading is "don't listen." The deep reading is you have to be careful which customers you listen to, and then you need to watch what they do, not listen to what they say.

The last part of this -- watch what they do / don't listen to what they say -- while perhaps superficially disrespectful is a key part of what I call the Medical Model of User Feedback.

Symptoms and Signs
When a (medical) doctor examines a patient she will usually ask for symptoms -- what is the patient's experience? -- and look for signs -- her own observations.

Generally signs are regarded as the more significant, since the patient is typically neither particularly well-trained at interpretation nor unbiased. This is why watching people is invaluable when tuning software features.

By all means listen to User Feedback and requests, but consider it an early step towards revision and improvement, not the last word.

Pareto and The Wedding Reception Principle

2007-06-14T15:38:00.000-07:00

Lately I have been thinking about points of diminishing returns, and perfectionism.

The Pareto Principle or 80-20 Rule says -- among other things -- that roughly 80% of benefit is derived from 20% of the work. Another statement is, "the first 90% of a task takes 90% of the time, and the last 10% takes the other 90% of the time".

Now, for maximum productivity, one should always pull-up short when the first 80% or -- thereabouts -- is covered, and move on to other tasks. But in practice there will be times when you need to go that last 20%. For example, if you are competing on quality, that last 20% is going to be important at least some of the time.

I have my own principle, The Wedding Reception Principle, which is even more useful than the Pareto Principle. It states that in any broad endeavour, if all aspects are up to a good-standard then people will be struck by the excellence of one-or-two outstanding aspects. On the other hand, if any one thing is sub-standard, that is what people will remember, regardless of whether everything else is exceptionally good.

For example, at a wedding reception, if the food is bad, that will be what everyone talks about, not how great the speeches were or how much fun the dancing was. But if the food was merely ok, and the speeches outstanding, it will be the speeches that everyone remembers and talks about, and their general impression will be positive.

In other words: Make everything good, nothing bad, and a few things extraordinary. And pick those things that you intend to be extraordinary carefully, because you will be fighting Pareto and spending lots of time on them. It would be a shame if they turned out to be relatively unimportant.

Kids and Language

2007-06-11T14:53:00.000-07:00

At time of writing my son is almost three-and-a-half, and my daughter is one-and-a-half.

Jake's English is exceptional, but he was slow to get started. Jake learned English vocabulary, structure, and some accent according to the Thomas the Tank Engine method.

He is now inventing words. My favorite so far is ignoying, as in "Daddy, stop ignoying me", to which I sometimes respond: "Jake you're ignoying me, too". I think it's a keeper. I must start using it around work :-)

Ella, on the other hand is more precocious, already saying many words and even a few two word sentences: "Herro Daddy". I have started trying to speak -- and latterly learn -- Hebrew in an effort to get Andrea to talk to the kids in her fluent Hebrew. It works this way: I speak in broken Hebrew and Andrea corrects me, and is reminded to use it a bit more, and apparently feels less self-conscious about her (perceived) lack of vocabulary.

[I am now trying to learn conversational Hebrew, and am enjoying making some progress, although I seem unable to reproduce the guttural "r" for love or money.]

Ella is already saying "Toh-dah!" (thank-you) with aplomb. Jake is more cool, sometimes imitating, but sans enthusiasm, and sometimes saying, "Don't speak to me like that!"

I think that if I keep talking Andrea will keep speaking and Ella will learn for sure. As for Jake, on this issue at least, I intend to continue ignoying him.

Good User Feedback

2007-05-27T16:37:00.000-07:00

Via Fiona (Austhink's Education Coordinator):

Startup screen is great, but how do I get it back?
Spell-check please!
Some well-heeled schools are getting the powerful combo of tablet PCs for staff and all students in conjunction with a projector (in preference to smart-boards)
Text pane open/close button goes missing
Some lap-tops have neither mice nor track-pads, making dragging of maps painful

Observations:

Many (most?) secondary-school students kick off an argument map with a question

Often encouraged to do so by their teachers

Students asking for links between boxes -- other than hierarchical relationships -- within a map
Kids are becoming more visual and audial
Connection to the synthesizing mind and the disciplined mind in Howard "multiple intelligences" Gardner's latest opus, Five Minds for the Future.

Other positives:

.NET is becoming more pervasive (as more products require it)
Installation process is smooth

Abstract or Separate

2007-05-27T15:44:00.000-07:00

As Rationale evolves we at Austhink -- the designers and programmers -- are again and again faced with a tension between on the one hand simplicity through separation, and on the other hand power through integration.

Each time we add a new feature we face the design decision of whether it should be deeply integrated into existing features, or tacked on somewhat separately. [Of course there is something of a continuum here.]

For example, the ability to add an image to any box generalizes the facility for images which were previously available only for basis boxes (and were in that case compulsory). The generalization has the following consequences:

Basis boxes may now have other images than the pre-defined ones
Basis boxes are now less special than previously

I claim point 2. because whereas previously basis boxes were

Visually distinct (on account of being the only boxes with images)
The only terminal category of box
Had a separate place in the epistemology of argument-mapping

Now that point 1 has been eroded, we are left with points 2 and 3. The argument in favor of these points are that they provide good "scaffolding" to ease the learning of the system, making them good for beginners, so they should be retained.

This is argument is analogous to the following:

Bicycles are difficult to learn to ride on account of their instability, so all bicycles should have training wheels.

Of course, in the case of bicycles we allow the training wheels to be removed, and we provide tricycles for small children and even for adults with limitations to their balance or who failed to learn to ride a bicycle sans training wheels when young.

So, when examining simplicity vs. power trade-offs the bicycle metaphor may be a good source of inspiration.

The 10 Comapments

2007-05-22T15:17:00.000-07:00

Today is Shavuot, which marks the giving of the 10 commandments to Moses (photo) and his homies.

To celebrate this occasion there we will be cheesecake for morning tea. Why cheesecake?

And to demonstrate that Shavout is not just about artery hardening goodies I have constructed a comparison chart of the original 10 commandments and a respected modern interpretation.

	The Ten Commandments	The Ten Comapments
Given to	Moses	Dan
By	God	Some dude
On	Stone tablets	A slightly soiled napkin
Where	Atop Mt Sinai	Outside a small cafe in Carlton
1	I am the Lord your God who brought you out of slavery in Egypt.	I am Rationale^TM your mapping tool who freed you from the bonds of confusion.
2	You shall have no other gods but me.	You shall have no other mapping software but me*.
3	You shall not misuse the name of the Lord your God.	You shall not omit the little ^TM symbol.
4	You shall remember and keep the Sabbath day holy.	You shall have a nice break between mapping exercises.
5	Honor your father and mother.	Pay your subscription / buy the upgrades.
6	You shall not murder.	You shall not own a Mac.
7	You shall not commit adultery.	You shall follow the Holding Hands rule, but that's all!
8	You shall not steal.	You shall use many sources, and give references.
9	You shall not bear false witness against thy neighbour.	You shall not construct defamatory example maps about your colleagues.
10	You shall not covet.	You shall not ask for too many new features at once.

*And bCisive.

A suspect for murder

2007-05-17T20:45:00.000-07:00

Joseph Laronge presents a useful comparison of two different styles of mapping applied to the problem of whether Bob is a suspect for murder.

The first is an argument map:

and the second uses Laronge's own "path-mapping" conventions which he calls "pyramid style":

I have taken the time to do my own argument map, which in a way which gives I think the best of both worlds:

The structure is largely taken from Laronge's particular path map, but
The co-premises are pulled out, making it easy to show where the reasoning and evidence are open to challenge

It looks like argument mapping in a legal context is ripe for advancement. It will need people with skills in both mapping and the Law to work together to figure out how best to do it, both in terms of refining the method and conventions, and developing a sufficiently rich visual language.

In my example I would like to have been able to indicate through a strong visual device the following "legal concepts", which are somewhat implicit at present:

A piece of cited law
Which which "side" is favored by each premise

This could be accomplished in a few ways, but I will not go into that point at this stage. I am amore interested in finding out what else deserves to be reified in these kinds of maps.

Ideally, once the visual language is sorted out it should be possible to provide "road-maps" and templates that can be readily molded to reflect a particular case.

A big job indeed!

Clumping: The Missing Mode

2007-05-16T14:45:00.000-07:00

Rationale -- the product that my working life revolves around -- currently has three mapping "modes": grouping; reasoning; and analysis.

Reasoning mode is for loose informal reasoning:

To tighten up the argument I use analysis mode, which allows me to break out the hidden premises:

Grouping mode allows me to create tree-like structures for non-reasoning purposes:

So while the reasoning and analysis modes provide specialized support for argument mapping, it is grouping mode that one turns to for all other tasks. I.e. Less sophisticated = more general.

And through the magic of our powerful "morphing" facilities it is possible to start working in one mode and then have Rationale convert the map into either of the other modes almost instantly. Very useful when you find yourself in the wrong mode!

So what's the missing mode?

In fact, it is possible to do reasoning in grouping mode, just without quite as much constraint as in reasoning mode, because fundamentally both of these modes manipulate "tree" structures.

What's missing is a mode which generalizes analysis in the same way that grouping
generalizes reasoning. Let's call this new mode clumping or clustering.

I am not quite sure what the applications will be, but I am confident that they will emerge.