Laws of Logins

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

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

1. Allow me to try or taste the service without entering a username and password (or I won't it use it).
2. Never supply username and password if the service is once only (or I won't use it).
   
3. 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

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?

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

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

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

Signs of Good Design

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?

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

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 ...