Software developers are not generally IO-bound. The speed at which I can type is not the bottleneck in terms of how fast I can produce software. I’m definitely CPU-bound. This means that there is little performance gain to be had from scaling out to 1 or more keyboards per developer. The pipe between my brain and the IDE is fairly idle a lot of the time, with occasional bursty traffic that still comes nowhere near 50% of the available bandwidth, even on a single half-duplex keyboard architecture.

As developers are generally CPU-bound, scalability can be achieved by moving to a multiprocessor configuration, with 2 developers sharing the same IO channel. The instruction pipeline optimization that can take place with a shared memory configuration can result in a better than linear performance increase.

I’ve worked on a few migration / rewrite /port projects in my time. They almost universally had no technical merit in and of themselves. From a developer’s perspective, a rewrite of an existing system basically means taking a stable, tuned application, freezing all new features, and writing it again in a language that’s newer, possibly more buggy, and probably less familiar to many of the team members, and delivering at best exactly the same features as the existing system, while taking several months to do it, with a risk of introducing new bugs along with it.

Migration projects are almost always done for political or cost reasons. Either the company has decided on a strategic plan to ‘go Java’ or ‘go .NET’, or (possibly less high profile, but potentially more significantly), is having a progressively harder time retaining developers with the skill set needed to support the existing system. Technology can also be made a scapegoat – so if a system is delivered that runs too slowly, or crashes a lot, the entire platform it happened to be developed with is proclaimed as ‘slow and unstable’, and the baby is thrown out with the bathwater.

Following a pub conversation with a colleague:

http://www.eecs.harvard.edu/~mdw/proj/seda/

http://foxtrot.sourceforge.net/

http://spin.sourceforge.net/

The Humble Dialog Box

Peelable UI’s

Looking for the price of an XBox on Amazon, I spent several futile minutes trying to find the ‘add to basket button’. In desperation I turned to the help page where I found this gem:

If you can’t see an “Add to Shopping Basket” button, it’s because the item isn’t available from Amazon.co.uk.

Okay. Right. Wonder what else they have listed that they don’t actually sell!! Why stop with XBoxes? Why not advertise trips to Mars, X-ray spectacles and rayguns?

Some very close friends of mine asked me to be the ‘official’ photographer at their wedding this weekend. I reluctantly agreed, against my better judgement, as they weren’t going to have a photographer otherwise. Having lived through the experience, and found surprisingly little useful advice on the internet prior to it, I thought I’d add my bit to the body of knowledge on the subject.

So, some things to remember when asked to photograph someone’s wedding:

• Unless you’re already a professional wedding photographer, don’t. Its an enormous responsibility. If a paid professional screws up a a crucial shot, some form of financial compensation can be negociated, and even if the wedding party end up hating them, they’re highly unlikely to meet them again. The same cannot be said of friends. So you’d better be very, very good friends with the bride and groom, and even if they forgive you for missing a vital shot, you’re still going to feel pretty bad about it.
• The better you know the couple, the higher the chances are that you are supposed to be in some of the photos. Better have a photographically inclined friend around who is not in the same groupings that you are.
• Use a good digital SLR, quality lenses and shoot raw. Unless you really are a professional wedding photographer, steer clear of film. You have to be able to rattle off shots like crazy, and check them in the field. You should expect to take between 200 and 500 shots.
• Have a manic eye for detail. Jackets, ties, buttonholes, pocket hankies, bride’s veil, people’s hair, backgrounds, head heights, positioning and spacing all need to be checked by you. Nobody else will notice at the time – its your responsibility to make sure everyone looks their best.
• You have to be able to impose your will on complete strangers. Get comfortable saying things like, ‘You, madam, in the hat! Is that your husband next to you? Could you at least pretend to like each other and stand a little closer together? Thank you so much,’ with sufficient charm to keep everyone smiling. This is surprisingly hard work – I was exhausted by the end of the day.
• Buy the most powerful flashgun you can find. Churches are usually lit by a combination of daylight, stained glass, tungsten and fluorescent lights, often all at the same time. Your flash needs to be powerful enough to fill a substantial space and overpower the other light sources to avoid colour casts.
• Photograph outdoors if possible. Avoid dodgy backgrounds like gravestones, and use fill flash.
• If photographing indoors use bounced flash whenever possible. Make sure you extend your flashgun’s reflector card if it has one, to form catchlights in people’s eyes. If the ceiling isn’t white or very close to it, use direct flash, and look for sources of daylight.
• Consider finding a high vantage point at the back (some churches have an organ loft or mezzanine) during the service and using a long lens with a wide aperture (f/2), beanbag or tripod and no flash to capture the exchange of vows. The couple will often turn around to be applauded after exchanging vows – be ready to capture this. Make sure you can get rapidly from your vantage point down to the couple if you need to capture the signing of the register, or anything at ground level during the service.
• Practice changing lenses – it should take you 5 seconds or less.
• Don’t use any equipment you’re unfamiliar with, or storage media you’ve never tested.
• Keep spares of everything in your pockets. Batteries for camera and flash, and several memory cards. Don’t keep your full cards/batteries in the same pocket as the used ones.
• Use a proper camera bag that opens up easily. It doesn’t have to be expensive, just easy to put stuff in and out of. Keep everything in the bag or on your person – you may need to grab it to get quickly to the next location.
• Use a zoom lens for the group photos. I took the majority of pics towards the 70 mm end of an 18-70 mm lens.
• Make everyone stand very close together – they need to be inside each other’s personal space to avoid ‘broken up’ looking groupings. People will not generally stand close enough to each other if left to their own devices. Make sure the bride and groom are dominant (in the middle, at the front generally works, with clear space between you and them), and get everyone else to turn towards them by 45 degrees or so. This lets you stand people closer together, and emphasises the wedding couple.
• Heads. Get the bride and groom to embrace and lean their heads towards each other, touching if they’re similar enough in height.
• Take several shots of each group – its very hard to get everyone looking their best at the same time, so you need to give the couple a selection to choose from.
• Crop in close. Sometimes the only difference between a ‘pro’ looking shot and a merely average one is the tightness of the framing.
• Did I mention not doing it?

Machine language is powerful. The programmer has absolute control over the machine. Anything that a computer is physically capable of doing, it can be made to do.

Machine language is not powerful. Even simple conceptual operations take many instructions to code. You’re forced to work in the machine’s terms and manually control all the devices, memory and cpu registers.

SQL is powerful. Its possible to write highly complex queries that tell the machine what information you want it to return to you without any knowledge of how it will go about finding it.

SQL is not powerful. It is not possible to tell the machine how do achieve something, only to ask it for information and hope it goes about the task in an effective way.

Java & .NET are powerful. The environment takes care of interacting with the devices, memory and cpu registers. Its easy to model human concepts on these platforms.

Java and .NET are not powerful. If low-level functionality is needed that was considered too dangerous by the system designers, there is no way to access it from within the environment.

Smalltalk is powerful. The environment takes care of interacting with the devices, memory and cpu registers. Its easy to model human concepts on this platform.

Smalltalk is powerful. Low level functionality is implemented in the same language as high level concepts. If access is needed, the code is accessible from within the environment. The virtual machine can be extended by adding custom primitives.

Smalltalk is powerful.