With Agile and Continuous Integration becoming popular, a significant number of development teams are using information radiators – mostly focussed on showing the latest build status. Information radiators are a very powerful way to aid communication and subtly adjust a team’s behaviour and attitude. The catch however is that it can be quite hard to control how you subtly adjust the team’s attitude because the pressure to change is so subtle.
Unneeded interfaces are not only wasted code, they make reading and debugging the code much more difficult, because they break the link between the call and the implementation. The only way to find the implementing code is to look for the factory, and see what class is being provisioned to implement the interface. If you’re really lucky, the factory gets the class name from a property file, so you have to look another level down.
ThoughtWorks are opening their new office right in the center of Manchester with a conference. The cost is £75 and places limited to 50.
I’m particularly looking forward to Dave Farley on continuous delivery…
It’s nice to read things like this and be able to think – meh, I already have to listen to him everyday at work. :) Basically, I’m really enjoying constantly having the feeling that I’m the dumbest person in the room because there’s always a ton of learning that comes out of that experience.
The current competition in the smart phone space between Android and iPhone is both fascinating to watch and provides for some quite vigorous and entertaining debates. I find one pair of arguments particularly entertaining:
It’s interesting how often the same person will attempt to leverage both of these arguments (or likely better worded variants thereof) without ever realising that by definition, they can’t both be true. If Android is outselling iPhone, then it would be impossible for Apple to have a monopoly and thus can’t abuse it1{#footlink1:1305386215210.footnote}.
One of the things I really enjoy about the software development teams I’ve worked with is their relentless focus on improving their overall productivity – producing more business value in less time and with less cost each every iteration. It’s largely this drive for productivity that drives developers to focus on quality – buggy code is hard to maintain and delivers little or no business value. Similarly it makes developers really care about the tools they use – the programming language, the OS, the IDE or editor, continuous integration, source control and all the other tools or systems they have to work with. When it comes to tools, nothing is ever good enough and we always want more. So long as that desire for perfection is balanced by careful, realistic prioritization it’s a fantastic thing to have in a team.
The last couple of weekends I’ve been fiddling with a skunk-works project to improve one of the internal web apps at work. Since it’s an internal tool and the entire development team run on Linux I’ve had the luxury of completely ignoring IE support. Previously I’ve felt liberated when I could drop support for IE6 but web development is a whole new world when you’re prepared to drop IE altogether – even IE9 wouldn’t have some of the things I’ve been happily using.
For the past three months I’ve been settling into my new role with LMAX developing a high-performance financial “exchange”1{#footlink1:1301173295622.footnote}, hence the silence on the blog lately. One of the things I’ve found extremely impressive about LMAX is the impressive acceptance test coverage and the relative ease with which they are maintained. Normally as a set of acceptance tests gets to be extremely large they can become an impediment to being agile and changing the system since a small change to the UI can affect a large number of tests.
i18n trap #1: I should have a simple way to map an Enum to a presentable string.
This seems eminently reasonable at first glance – there are many cases where you have one of a set of things and need to inform the user which one you have. Unfortunately human language, unlike their computer language counter-parts, are context-dependent. So that single Enum value in code could well be presented with many different words when presented as part of different sentences or in different contexts.
You may have heard something about Chrome dropping support for H.264 from it’s Video tag implementation in favour of WebM. The reactions are unsurprisingly strong and partisan. From my point of view I see that:
As a result, the only company who can exert any serious leverage on web video formats is Adobe. If they ship a version of Flash that supports WebM, suddenly it has traction very nearly equal to that of H.264 (but H.264 would still have the advantage of also working on iOS devices). For WebM to have the advantage Flash would have to support WebM and disable support for H.264.
There has been a trend over the past few years for open source projects to routinely ask for “donations” through a donate button on the site and increasingly in the software itself. I put “donations” in quotes because in the vast majority of cases these aren’t payments to a charitable organisation — they go straight into the pocket of the one and only developer.
CSS3 introduces the very handy columns support which is implemented in WebKit and Firefox browsers going back a fair way and degrades gracefully in all browsers that don’t support it (which appears to include IE9 sadly). The downside however is that support for the corresponding column-break property to control where column breaks are allowed to occur doesn’t appear to exist despite documentation suggesting it should. So for example1{#footlink1:1293713493905.footnote}:
Many browsers include user preferences to select preferred colours for text, backgrounds and links. This is intended as an accessibility feature so that people with limited vision, dyslexia or other disabilities can choose a colour scheme that makes it easier for them to read web pages. In theory it’s a great idea. In practice however it seems to be nearly useless.