-
"I think recognising this – when there is a path from a crisis that involves risk but rewards you hugely – with something you wouldn’t have imagined, is at the very heart of design. It’s certainly an incredible feeling when it works, when the judo-flip flows just so, and you end up somewhere brilliant." Yeah. I really, really need to trust that more when I feel it.
-
"Though adept at mathematics and engineering science, his inventions were all human-centred and focused on the experience and enjoyment of the user. He abandoned his design of a steam motorboat engine, for example, because once he had developed it to rival diesel power it lost its suppleness and "was not a nice thing any more". His car suspensions and the cycle developments were entirely aimed at providing a superior experience for the user. He was very taken, through his association with Bridgestone, with the Japanese sense of the "spirit" of an artefact, reflecting its origins and the care with which it was made. He liked the idea that by seeing and using something one can detect this "spirit", which fitted his own conviction that manufacture and industry are morally rewarding. "Man should make things … Make a profit, of course, but don't take the money gain as the prime judgment."" Great paragraph from this obituary of Alex Moulton.
-
Wonderful article about Hackney – and, specifically, a natural history of the borough as it is right now. The history of social housing throughout the area is particularly interesting; also, I found the distinction between "gentrification" and "yuppification" useful. Ignore the title – it is a meaty piece, with about 2% of it being about hipsters.
-
"…if any one of the participants at the meeting starts to deviate away from the subject, repeat themselves or get a little carried away with their topic, the "Scrum master" presents them with the baseball cap to wear – the idea being to "cap" the conversation at source! This indicates that the person presented with the cap is now prohibited to speak until asked to contribute again, or until the cap is passed to someone else during the course of the meeting." Iiinteresting.
-
Lots of good analysis and tips in here. It's very much not a selection of things to do, more a selection of issues noticed and ways to fix them – many of which are contradictory.
-
"A silly version of postmodernism would suggest that contemporary scientific claims are identically as valid as those made in the dark ages, whereas really they are valid in different ways. Whereas a smart critique of rationalism (and of the Dawkinsesque pastiche of Enlightenment) is one which recognises the evolutionary nature of science, capitalism, culture, such that we cannot throw off our current mindset, culture or language, but nor are we imprisoned in it. We recognise the present as constitutive of who we are, but also as a single moment in an unfolding drama with no apparent conclusion." Cracking writing from Will – and some good stuff linked from this.
-
"Agile is like teen sex: Everyone wants to do it, many say they're doing it, only some actually are, and very few are doing it right." Yup.
-
"Just remember, 'There’s only us.'" Some good analysis; fair and even-handed.
-
"Sometimes you want to follow someone on Twitter, but you don't want them to know you're following them. We present to you TweetStalk ‒ the simple way to stalk Twitter users without having to follow them." Oh for heavens' sake.
-
"A man can only eat so many cheap sniper shots, so many deaths by machine gun from over 75 meters away, so many attempts at a final tricky jump to a tiny ledge across a giant gap, so many degrading restarts… Sometimes I hate games so very much." Sadly, much of this is pretty true.
-
"I don't begrudge Blow an attempt at addressing important historical events, but the weight of the atomic age seems too much to address with a few lines of text that feel incongruous with the rest of the production." This is, I think, a worthwhile point. I'll be returning to the whole "atomic bomb" question in a blogpost soon, I hope.
-
"Given that Valve is being forced to charge for the update, they wanted to ensure that 360 owners were getting their money's worth." Such a shame they have to charge for it – but still, more TF2 on 360, and that's a good thing from my perspective.
-
A nice simple explanation of what using Git is really like.
-
"What the hell is wrong with me? There are a lot of ways to win at Civilization Revolution that do not involve taking a happy, peaceful city and reducing it to a smoldering gravesite filled with radioactive trinitite." Clive Thompson on a case of Walter Mitty syndrome.
-
"Keldon Jones has published an artificial intelligence opponent for the game Blue Moon with an user interface written with GTK+ toolkit. This is a native Mac OS 10.5 version of the game written with Cocoa, so there's no need to install X11 and GTK+ libraries. It runs straight out of the box (on Leopard)." Heck yes.
-
"This is a write-up of my diploma project in interaction design from the Oslo School of Architecture and Design. The project is entitled ‘Adventures in Urban Computing’ and this weblog post contains a brief project description and a pdf of the diploma report." Well worth a read, and beautifully presented. I need to chew over this more.
-
"It's a shame to me that a game with Braid's narrative, artistic, and aesthetic aspirations is inaccessible to so many people hungry for exactly those things." Yes. Much as I adore it, Braid can be awful hard at times. A smart game for smart gamers, alas.
-
"A popular misconception about agile is that it doesn’t allow for plans. This isn’t true. Agile focuses on the activity of planning rather than focusing on a fixed plan."
The Continuous Integration Barometer
14 March 2007
This is an idea spun out of conversation with Ben and Paul at last night’s LRUG – a physical device for alerting developers working in a continuous build environment as to how far they are from the trunk.
Because of the rate of change on an agile project, it’s important to keep your own personal codebase as close to the trunk as possible, otherwise you’ll spend a long while working on code that doesn’t fit with the current state of the system, or working around issues which may have been fixed. It’d be good to have some sort of physical display to alert you to this, rather than relying on typing svn up every five minutes.
Enter the continuous build barometer. It’s dead simple: it’s a dial you connect to your computer via a USB connection. The moment you do a checkout, the needle sets itself to 0. And then, as your codebase diverges from the trunk, the needle indicates how far (proportionally) your code diversifies from the original. And, of course, the moment you check in, the needle resets itself to zero.
Ideally, the continuous-build barometer needs to be made out of something reasonably heavy – I have this image of brass and wood, much like this example, if only to convey the weight that “checking in often” actually carries. In terms of making one… dial indicators seem to be quite pricey. It’d be easy to prototype with something like this ten-bar LED display, an Arduino board, and a short-ish script to compare the trunk with your local version, cronned to run regularly. Of course, I think the physical nature of the object is important, but it’d still be interesting to see what a working version in any form looked like.
That was one of my favourite things this month’s LRUG gave me, and it’s not really even code. Now: who wants one?
The latency of software development, pre- and post-launch.
23 February 2007
In a recent post about offshoring development work, Ryan Carson explains that the way you know when you’ve outgrown a freelance developer is this:
Getting bugs fixed and new features implemented starts taking fricken’ forever.
There’s some interesting discussion on the post – about eastern-European wage rates, about freelancing, etcetera – but there was one elephant in the room that nobody really mentioned, and I really think it’s necessary. And that’s this:
once your application is live, everything will take longer.
Whilst you’re in the build process, you can turn on a dime; you can commit new code at a moment’s notice, change the direction of the codebase or even the application, churn out features at a remarkable rate. And, when something doesn’t work (despite having passed the test suite… which you do have, right?), you patch it and move on. It’s a doozy.
Once you’re live, everything changes. You’ve got an active audience using the site – you might even have paying customers. You can’t afford for a single thing to go wrong. New features are no longer about build it, run the tests, check it in, deploy. Your testing on the development box has to be more fastidious. The integration between new functionality and the existing needs to be really well thought through. The design needs to be seamless with that which exists already. And, if it goes live and there’s still one of those totally unforseen bugs… you need to be ready to roll back at a moment’s notice, and put the feature on hold until it’s ready.
This is not new. Some teams are lucky enough to make many deploys daily; most can muster up daily fixes; some might go to weekly. But the effort that a feature requires post-launch is far more than it does pre-launch.
So it’s inevitable – freelancers or no – that the pace of development is going to fall off a bit post-launch. Hopefully, only a bit – but it’s not going to be the same rate unless you’re extremely lucky. You’ve also got to keep your users in mind, and break them into new functionality slowly.
It’s a hard transition, going from the development site to live. To you, as an owner, a developer, it feels like the same product – so the change in pace is a bit frustrating. And it’s important to keep the pace as fast as possible. Some fixes are critical, and need to go out the door the instant they’re done; others can wait a little longer – a day or two, if necessary – for release. It’s a rare, focused, hugely talented team that can splurge out new features like a machinegun.
Now, I’m sure that the problem is compounded by avoiding maintenance contracts (and so having to re-contract and re-hire) and having developers whose time is precious. But it’s always important to bear in mind that the latency of any web software development shoots up post-launch. So if it does: don’t immediately reach for the outsource button. Take stock, have some patience, and see what the product needs – how often it needs to be released, how often it needs to be improved. And then you can make that call a little better informed.
The other golden rule, incidentally, is never deploy on Friday. I hope the reasoning behind that is obvious.