Extreme programming 80s style - epic fail

Fri 06 August 2010

My first brush with programming was on the Sinclair Cambridge Programmable Calculator. A mathematics teacher got me hooked - if I remember well he was later knocked down and killed by a milk float.

Later I messed about on the ZX80, ZX81, ZX Spectrum, and Sinclair QL while sailing gracelessly through school. I never did thank my teachers properly.... too late now, I guess, but thank you very much.

And I wrestled with the Dragon - my first experience of "pair programming"... me and Steve Sharpe trying to re-write the Star Trek game - we missed by a mile... sadly Steve died a few years later - he'd have been a mad professor by now.

So by this time I'd had first-hand exposure to the realities of professional software development, ie

  • coding all night
  • delivery failure
  • getting published (i wrote a game for the Spectrum)
  • copyright theft (some turd fan copied my game and got it republished),
  • getting paid (3D space invader game for the QL - £500. Not bad for two weeks' work)

I wanted to make things - so I did real Engineering Degree at a real University - only to discover that "Software Engineering" was on the syllabus. Ha!

Having already done some actual coding it was pretty funny to hear lecturers talk about programming in Z and Occam like they were going to change the world. This was obviously bullshit rocket science, not engineering - concepts too hard for the lecturers students to grasp.

Z was great in theory - a way to specify programs in an incomprehensible format mathematically. Only trouble was, and is, that in the real world the people who need to specify software don't have a snowball's chance of understanding Z (or finite state machines, or polymorphism, or Scrum but I'm getting ahead of myself...)

I've been hitting this same problem from various angles ever since. As a programmer, designer, consultant, project manager, troubleshooter, director, alcoholic.... so that's thirty years, on and off... and still I'm struggling to get clear what it takes to make software reliably and efficiently.

Note I'm talking about tough software - o/s level stuff, comms, device drivers, real-time apps, big systems. Not your grandma's web site or an iPhone fart app.