Freelance Unbound has some great laws, clearly learned the hard way, about… well, supposedly about website launches with new content management systems. But actually they can be generalised to be laws of almost any kind of big project with a strong technology element. Laws of physics? Laws of the land? Either way, you don’t need … Continue reading
Agile comes with tons of literature on how to organise work at a very detailed level. How much of this treadmill is activity for activity’s sake, rituals, and religious manifestations of an ‘Agile Sub-Culture’ aimed at integrating a growing workforce? Can this relentless ‘heart beat’ and this esoteric jargon stifle innovation and alienate the very … Continue reading
I’ve been reading a bit about lean working recently, and this is a bit about what I’ve learned. Lean software development is a fascinating step on from Agile, but its history is in manufacturing cars and to date I’ve only been reading up on lean manufacturing, not lean development. There are two reasons for this. … Continue reading
…which was a semi-regular event of Wii tennis in the office, but a very useful part of our R2 work, too. Each launch required a small army of technologists to be on-hand: to run the various scripts, check the results, and deal with any problems that might arise. We needed to arrange these teams carefully … Continue reading
…which was the penultimate step before a launch, after the software had been built and released, and before the technical work to finally lift the curtain. One of the big changes that was part of R2 was how we structured our content — our information architecture. Previously each piece of content lived in a section, … Continue reading
…which is a much misunderstood subject. The R2 team consisted of a number of QAs, and the most obvious artifact that the QAs produced and worked with was the test script: a series of detailed instruction that explained what to test and how to test it. For this reason it’s too easy to dismiss QAs … Continue reading
…which was, and is, a hugely important part of our software development, and something that took a long time to learn to do well. Pair programming is when two developers sit at one machine and one keyboard to write the software. It’s very difficult to do: the driver has the pressure of someone watching their … Continue reading
…which is a word that we came to understand only slowly, particularly as a counterpart to the word “challenge”. As we worked we inevitably came across problems; Nigel, our indefatigable programme manager, would insist on calling them “challenges”, and casting possible actions as “opportunities”, to the point that it became a running joke. But problems … Continue reading
…which stands for “just do it”, and was the unofficial name of one of the development teams which sat alongside the R2 teams. One key principle we had from the start of the project was that other development work couldn’t stop for the sake of the site rebuild. There might be less of it, but … Continue reading
I’ve just finished a fortnight’s holiday which I (foolishly) spent mostly in front of a PC developing a never-ending little application. But unexpectedly, despite the trivial nature of my project, I rediscovered a number of important lessons more usually associated with serious application development. The software I’m writing is a just a little Firefox plugin. … Continue reading
